Pull Request

1. 主要解决的问题

动态 shape 场景下，前端调用 AutofuseTiling(s0, s1, ...) 获取 tiling 解。后端经过 ASC 图序列化、优化和 impl graph 生成后，可能丢失原始前端 shape symbol，导致前后端对动态/静态 shape 的判断和 AutofuseTiling ABI 不一致：

• 后端 impl graph 残留符号较少，可能生成无 shape 参数或参数不完整的 AutofuseTiling；
• 前端仍按原始 ASC 图的完整符号列表调用；
• 前端按照数字后缀自然排序，后端按照字符串排序，对于ks0, ks1, ks2, ks10的符号，前后端的顺序就会出现不一致；
• host 调用时函数参数布局错位，最终触发 coredump/SegFault。

此外，ASC 图可能通过 CreateAxis(..., Symbol("s0")) 直接保存 shape symbol，而不注册到 GetAllSizeVar()。如果只读取 GetAllSizeVar()，会错误生成零动态参数的接口。

2. 修改方案

2.1 前端 ABI 符号捕获与排序

• 在图优化、RemoveDanglingNodes 等可能改写或丢失符号之前，从原始 ASC 图捕获前端 shape symbol；
• 同时收集显式 SizeVar 以及轴、repeat、stride 等表达式中的自由符号，覆盖 Symbol("sN") 直存场景；
• 对 ksN 按数字后缀自然排序：ks0, ks1, ks2, ks10；非 ksN 符号保持确定性字符串排序；
• 通过 frontend_shape_vars_collected 区分“前端确实没有动态符号”和“旧结果未采集元数据”。

2.2 对外接口与内部 tiling data 分离

• 对外 AutofuseTiling、Inductor/Pgo 入口、shape 参数、缓存 key 和静态 shape 接口使用完整前端 symbol 列表；
• GetFrontendShapeVars() 作为兼容访问入口，旧结果回退到 origin_vars；
• 内部 tiling data 生成仍保持原有逻辑：IsStaticSchedResult() 继续基于 impl graph 的 origin_vars 判断，避免因前端额外 symbol 生成过多 tiling data；
• IsFrontendStaticSchedResult() 仅用于对外 ABI 的静态/动态接口判断，保证函数签名与前端调用一致。

2.3 代码流程图

flowchart TD
    A[原始 ASC 图] --> B[收集 SizeVar 和表达式自由符号]
    B --> C[ksN 自然排序/去重]
    C --> D[frontend_shape_vars]
    D --> E[对外 AutofuseTiling ABI 和静态判定]
    D --> F[shape 参数、Pgo、cache key]
    G[优化后的 impl graph origin_vars] --> H[内部 tiling data 静态/动态判定]

3. 代码修改流程

• autofuse/common/ascgraph_info_complete.*
  • 增加原始 ASC 图 frontend symbol 捕获、ksN 排序和直接表达式 symbol 恢复；
• autofuse/optimize/optimize.cpp
  • 在优化前保存 frontend symbol metadata；
• autofuse/common/schedule_result.h、common_utils.*
  • 增加 frontend symbol 字段、兼容访问器和 frontend ABI 静态判定；
• autofuse/codegen/codegen_tiling*.cpp
  • 对外接口相关代码使用 frontend symbol；内部 tiling data 静态逻辑保持 origin_vars；
• 测试文件
  • 增加 frontend symbol 优先级、回退、自然排序、ASC 表达式 symbol 恢复及端到端 ABI 顺序验证。

4. 测试用例说明

本地验证

• cmake --build build --target optimize_ut -j 8：通过；
• cmake --build build --target pgo_add_abs_inductor_test_codegen -j 8：通过；
• 相关 E2E 目标代码编译通过；本地直接运行受已有 CANN 动态库混装影响，出现 libascir.so 未定义符号，非本次代码编译错误。

远端流水线

• 流水线：#1044214；
• 提交：694862c4；
• 结果：success；
• ST_Test_autofuse_ascendc_api：通过；
• PR 当前已恢复 ci-pipeline-passed label。

新增/覆盖用例

• FrontendShapeVarsTakePrecedenceOverImplVars：impl graph 丢失符号时仍保持前端完整列表；
• FrontendShapeVarsFallbackToOriginVars：旧结果兼容回退；
• NormalizeKsNamesUsesNaturalOrder：验证 ks10/ks2/ks0/ks1 排序；
• CollectsOriginalAscGraphSymbolsBeforeOptimization：验证原始 ASC 图符号捕获；
• CollectsSymbolsEmbeddedInAxisExpressions：验证轴表达式直接使用 Symbol("s0")；
• FrontendShapeAbiKeepsNaturalKsOrderWhenImplDropsSymbols：端到端验证 AutofuseTiling 签名和顺序。

5. 核对清单

• 已定位动态 shape 前后端 ABI 不一致根因
• 已保持内部 tiling data 生成逻辑不变
• 已补充符号恢复、排序和 ABI 回归测试
• 已执行 clang-format、pre-commit 和 OAT 检查
• 远端 ST_Test_autofuse_ascendc_api 已通过
• 未执行 /workspace/CANN-DevTool/att_gene bbit 验证：该路径不存在，实际目录为 /workspace/CANN-DevTools/att_generalization

6. 其他信息

• 本次修复不需要修改前端调用约定；后端从原始 ASC 图恢复完整 symbol 并统一顺序。
• 未修改 /workspace/CANN-DevTools 工作区中的既有用户改动。
• 未新增 tiling data，只修正对外接口使用的 shape symbol 集合和顺序。