Pull Request

1. 主要解决的问题

PGO 多 Group/TopN 场景中，生成或恢复的 block_dim 可能超过硬件实际 AIV 数；同时存在以下关联失败链路：

• 动态 CORENUM 表达式在 solver 前被提前求值，搜索变量尚未赋值时可能触发除 0（SIGFPE）。
• tiling case、PGO 候选和静态 tiling 入口未完整传播失败，可能继续使用无效候选或未初始化输出。
• PGO 配置文件可直接恢复超预算 block_dim，且失败回退前会污染实时 tiling 的初始状态。
• 多 Group 场景未区分串行与并行 launch 语义，可能错误聚合 core budget。

2. 修改方案

• 将 CORENUM 保留为显式 solver 约束；依赖搜索变量的 CORENUM 表达式不再在 DoTiling 前提前求值。
• GeneralTiling 后校验每个 tiling case 的 block_dim <= corenum_，fused 顶层再次校验聚合结果；超预算返回失败，不做静默截断，避免 tile 漏算。
• 串行 Group 的外层 block_dim 取各 Group 最大值；并行 Group 按求和语义安排 block offset，并限制在当前硬件 probe 范围内。
• Inductor modeled/measured TopN 搜索统一使用 min(limit->aiv_num, g_no_limit_res.aiv_num) 作为可用 AIV 数。
• PGO 配置增加 flag、数据长度、memcpy_s 和 block budget 校验；先读取到临时副本，仅校验成功后写回，失败时使用未污染的实时 tiling 状态重新搜索。
• PGO 搜索只向 batch callback 传递有效候选，并在无新增候选时返回失败。
• AutofuseTilingWithConfig 失败后立即向 C++ tiling/静态生成入口传播；静态生成返回空结果时，两个 Python 编译入口抛出明确异常。

3. 代码修改流程图

flowchart TD
    A[获取实际 AIV/UB 资源] --> B[初始化 tiling core budget]
    B --> C{PGO 配置有效且 block_dim 合法?}
    C -- 是 --> D[提交 PGO 临时副本]
    C -- 否 --> E[使用未污染状态实时搜索]
    E --> F[solver 执行 CORENUM 约束]
    F --> G[各 tiling case 计算并校验 block_dim]
    G --> H[串行 Group 取 max / 并行 Group 求和并安排 offset]
    H --> I{聚合 block_dim 不超过硬件预算?}
    D --> I
    I -- 是 --> J[TopN 仅保留有效候选并执行 profile]
    J --> K[输出选中 tiling 或静态 kernel]
    I -- 否 --> L[逐层返回失败]
    L --> M[实时搜索 fallback 或 Python 编译异常]

4. 测试用例说明

4.1 UT/静态检查

4.2 PGO 实机验证

验证环境：CANN 9.2.0，Ascend950PR_9579，硬件 AIV 数 56；用例位于 /workspace/CANN-DevTools/att_generalization。

选择 ATT-CG-01：6 输入连续 Add + Pow/Mean/Rsqrt RMSNorm，shape 为 (1, 2048, 1024)，同时覆盖 Reduce、多个 schedule result/group 与 PGO TopN，是本问题最直接的回归图。

验证前执行：

cmake --build build --target aihac_codegen -j 8
cmake --build build --target pyautofuse -j 8

运行时通过本地 package path/LD_LIBRARY_PATH 成套加载本分支 pyautofuse.so、libaihac_codegen.so 及 graph/expression 依赖，避免新旧 C++ ABI 混用；实测加载路径为：

/workspace/graph-autofusion/build/autofuse/compiler/py_module/pyautofuse.so
/workspace/graph-autofusion/build/autofuse/libaihac_codegen.so

分别执行：

python -m att_generalization.run_att_cache_guard --topn 1  --warmup 2 --repeat 5 --device npu:0 --att-profiling
python -m att_generalization.run_att_cache_guard --topn 10 --warmup 2 --repeat 5 --device npu:0 --att-profiling

结论：Top1/Top10 均完成 PGO host/device 编译、候选 profiling、NPU 执行和精度比对，未出现 SIGFPE、core dump 或超核数 block_dim。

Top10 实际编译的 10 个候选外层 block_dim 为 53, 52, 53, 54, 54, 52, 49, 52, 49, 46；PGO 搜索结果中 block_dim > 56 的数量为 0。

5. 核对清单

• 代码遵循项目代码风格，并通过 clang-format/ruff
• 已完成相关 C++/Python 自测
• 已在 Ascend950PR_9579 完成 PGO Top1/Top10 实机验证
• 已核验全部搜索结果和实际编译候选 block_dim <= 56
• PR 标题使用 fix: 类型标签
• 已阅读并遵守 CONTRIBUTING.md
• 未修改对外 API/ABI、CMake 或打包布局
• 文档更新（本次为内部 bug 修复，无用户接口文档变更）

6. 其他信息

• 原问题环境为 Ascend950PR_9589（AIV=64）；本次补充验证环境为 Ascend950PR_9579（AIV=56），覆盖了更小 core budget 下的 TopN 行为。
• 首次尝试仅覆盖本地 libaihac_codegen.so、仍使用安装包旧 pyautofuse.so 时，在 graph/expression 对象析构处出现 ABI 混用崩溃；改为成套加载本分支 binding 和依赖后 Top1/Top10 均通过。该现象属于验证部署组合问题，不是 PGO 流程回归。