0
代码
代码
Issues
Pull Requests
讨论
Wiki
分析
0
cann-robotcann-robot【feat】: v35 ReduceMin/ReduceMax/ReduceAll/ReduceAny 三层性能建模实现
de443d99创建于 6 天前历史提交
文件最后提交记录最后更新时间
cache
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前
extra_info_gen
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前
generator_utils
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前
preprocess
【feat】: v35 ReduceMin/ReduceMax/ReduceAll/ReduceAny 三层性能建模实现 Co-authored-by: zhang_shengjie<804425610@qq.com> # message auto-generated for no-merge-commit merge: !448 merge fix_reduce_perf_model into develop 【feat】: v35 ReduceMin/ReduceMax/ReduceAll/ReduceAny 三层性能建模实现 Created-by: zhang_shengjie Commit-by: zhang_shengjie Merged-by: cann-robot Description: # Pull Request ## 描述 ### 一、主要解决的问题 #### 1.1 Reduce API 缺少 V2 性能建模入口 原有 V2 API perf 路径主要覆盖 elementwise、data move 和已有 RegBase 向量函数，ReduceMin/ReduceMax/ReduceAny/ReduceAll 缺少能感知 Reduce 语义的建模入口，无法区分： - AR 与 RA Reduce pattern - B64 与普通 dtype 的向量指令成本差异 - reuse source 与 non-reuse source 的拷贝路径差异 - multi-reduce 场景下 copy merge 与 elementwise merge 的尾部成本 #### 1.2 Reduce shape、stride、merge 语义没有统一载体 ATT parser 已经能拿到 input/output repeat、stride、loop axis 等信息，但后续 perf model 缺少结构化参数，只能在 ASCIR adapter 中临时推断。该分支把 Reduce 专用参数沉淀到 codegen::ReduceSpecificParams，让 parser、ASCIR adapter 和 AscendC API perf 共用同一套语义。 #### 1.3 性能公式缺少可读拆解 复杂 Reduce 公式生成后只落在 pipe_res 和 ternary 变量中，review 或定位 tiling case 时难以直接看出每段公式对应的建模分支。该分支新增 PerfBreakdownGroup / PerfBreakdownItem，并把 breakdown 传递到 tiling code annotation。 #### 1.4 测试覆盖不足 新增 Reduce perf model 覆盖面较大，涉及 Common 合轴、ASCIR 注册、RegBase、AscendC API、符号表达式和多 reduce merge，需要补充 UT/ST 覆盖。 ### 二、修改方案 #### 2.1 Common 层新增 Reduce 专用参数模型 autofuse/common/codegen_api_param/codegen_api_param.h/.cpp 新增： - ReducePattern: 区分 AR / RA - ReduceMergeMode: 区分 none、copy、elementwise merge - ReduceMergedDims: 保存归约后的 {first, last} 二维建模形态 - ReduceReuseInfo: 标记输入是否只被当前 reduce 使用 - ReduceSpecificParams: 汇总 reduce_type、pattern、merge_size、merge_times、reuse 等信息 - BuildReduceMergedAxisPlan / BuildReduceMergedShape / BuildReduceSpecificParams: 根据 repeat、stride、dtype size 生成统一 Reduce 建模参数 合轴逻辑以 input/output stride 是否为 0 判断 first/last 归属，并在需要时按 32B 对齐补齐尾轴尺寸。 #### 2.2 Parser 阶段填充 ReduceSpecificParams 新增 autofuse/att/gen_model_info/parser/reduce_specific_params_builder.cpp/.h，并在 AscendGraphParser::ConvertNodeInfos 中调用： - 识别 Max/Min/Mean/Prod/Sum/Any/All/ReduceMax/ReduceMin/ReduceAny/ReduceAll - 根据 output 最后一维 stride 是否为 0 推断 AR / RA - 根据 loop axis 与 input/output stride 关系判断是否需要 multi-reduce - 从 loop axis repeat 生成 merge_times - 通过输入 fanout 判断 reuse.is_reuse_source 同时 ParserSubAxis 保存 axis id，保证后续可通过 attrs.loop_axis_id 找到真实 loop axis。 #### 2.3 ASCIR Reduce adapter 负责上下文转换与注册分流 新增 autofuse/v35/att/api_perf_register/ascir_reduce_api_perf_v2.cpp/.h： - 将 codegen::ReduceSpecificParams 转成 ascendcapi_v2::ReduceApiPerfContext - 对当前 shape 重新构造 merged_dims，避免静态参数和实际 shape 不一致 - 对缺失 merged dims 的场景 fallback 到 last-axis merge - Max/Min/Any/All 在有 reduce params 时走 Reduce perf，无 reduce params 时保持 elementwise fallback - 注册 ReduceMax/ReduceMin/ReduceAny/ReduceAll 的 V2 perf 入口 #### 2.4 AscendC API 层新增 Reduce perf model 新增 autofuse/v35/att/api_perf_register/ascendc_api_perf/reduce_api_perf_v2.cpp/.h，核心入口为： - ReduceMinPerf - ReduceMaxPerf - ReduceAnyPerf - ReduceAllPerf 内部统一走 ReduceApiPerf，按 dtype、pattern、reuse、merge mode 分支： - logical reduce: Any/All - AR-B64 与 AR-normal - RA-B64 与 RA-normal - aligned / unaligned 子路径 - tree reduction 成本 - copy merge 与 elementwise merge 成本 - 256B vector block 与 B64 特殊 repeat 元素数 输出写入 perf.pipe_res[PipeType::AIV_VEC]，同时写入 perf.perf_breakdowns 供 tiling annotation 展示。 #### 2.5 RegBase 与 DataMove 路径整理 - ascendc_regbase_perf.cpp/.h 新增 ReduceMinPerf / ReduceMaxPerf，通过 VF 表统一计算 RegBase reduce min/max 成本 - B64 compare 分支抽成 CompareB64SpecificPerf - ascendc_api_perf_v2.cpp 中 DataMove 逻辑迁移到 ascendc_api_perf/data_move_api_perf_v2.cpp/.h #### 2.6 perf breakdown 贯穿生成链路 - autofuse/att/base/perf_breakdown.h: 新增 breakdown 数据结构 - ModelInfo: 保存 perf_breakdowns - PipePerfExpr: 从 API perf 输出收集 breakdown，并随变量替换更新表达式 - ArgsManager: 保存、替换和对外提供 breakdown - TilingCodeGenImpl: 在生成 tiling case annotation 时追加 Reduce perf breakdown ### 三、代码修改流程图 #### 3.1 多文件调用关系图 ```mermaid graph LR A[AscendGraphParser<br/>ConvertNodeInfos] -.-> B[Reduce params builder<br/>FillReduceSpecificParams] B -.-> C[Common params<br/>BuildReduceSpecificParams] C -.-> D[NodeInfo.reduce_specific_params] D -.-> E[ASCIR reduce adapter<br/>BuildReduceContext] E -.-> F[AscendC reduce perf model<br/>ReduceApiPerf] F -.-> G[PerfOutputInfo.pipe_res<br/>AIV_VEC] F -.-> H[PerfBreakdown<br/>semantic items] H -.-> I[PipePerfExpr and ArgsManager<br/>replace symbols] I -.-> J[Tiling code annotations<br/>case explanation] C -.-> K[Common UT<br/>merged shape] F -.-> L[Reduce perf UT<br/>AR RA B64 merge reuse] style B fill:#90EE90,stroke:#006400,stroke-width:2px style C fill:#90EE90,stroke:#006400,stroke-width:2px style E fill:#90EE90,stroke:#006400,stroke-width:2px style F fill:#90EE90,stroke:#006400,stroke-width:2px style H fill:#90EE90,stroke:#006400,stroke-width:2px style D fill:#FFD700,stroke:#B8860B,stroke-width:2px style J fill:#FFD700,stroke:#B8860B,stroke-width:2px ``` #### 3.2 ReduceApiPerf 分支流程图 ```mermaid flowchart TD S([ReduceApiPerf]) -.-> V[Validate context and dtype] V -.-> L{Logical reduce} L -.-> LG[Build logical reduce cost] L -.-> P{Reduce pattern} P -.-> ARD{AR B64 dtype} P -.-> RAD{RA B64 dtype} ARD -.-> ARB[Build AR B64 cost] ARD -.-> ARN[Build AR normal cost] RAD -.-> RAB[Build RA B64 tree cost] RAD -.-> RAN[Build RA normal tree cost] LG -.-> M{Merge mode} ARB -.-> M ARN -.-> M RAB -.-> M RAN -.-> M M -.-> O[Write AIV_VEC result] M -.-> CP[Add copy merge cost] M -.-> EW[Add elementwise merge cost] CP -.-> B[Append perf breakdown] EW -.-> B O -.-> B B -.-> R([Return ge.SUCCESS]) style S fill:#90EE90,stroke:#006400,stroke-width:2px style ARB fill:#FFD700,stroke:#B8860B,stroke-width:2px style ARN fill:#FFD700,stroke:#B8860B,stroke-width:2px style RAB fill:#FFD700,stroke:#B8860B,stroke-width:2px style RAN fill:#FFD700,stroke:#B8860B,stroke-width:2px style CP fill:#FF69B4,stroke:#C71585,stroke-width:2px style EW fill:#FF69B4,stroke:#C71585,stroke-width:2px ``` ## 变更类型 请选择本次引入的变更类型： - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 暂无。 ## 如何测试 ### 一 测试用例说明 #### 1.1 单元测试 重点覆盖： - CodegenApiParamReduceTest.*: BuildReduceSpecificParams、copy mode、invalid input、rank mismatch - UTestReduceMinMaxApiPerfV2.*: RegBase reduce min/max、AR/RA、B64、symbolic dim、reuse、multi-reduce merge、ASCIR 注册与 fallback - UTestAscirPerfV2.*: 既有 ASCIR V2 perf 路径回归 推荐命令： ```bash source ~/Ascend/cann/bin/setenv.bash bash scripts/test/run_autofuse_test.sh --ut -j10 ``` 已有构建产物时可定向执行： ```bash build/autofuse/tests/ut/att/att_ut --gtest_filter=UTestReduceMinMaxApiPerfV2.*:CodegenApiParamReduceTest.* ``` #### 1.2 系统测试 重点覆盖： - TestAscendcApiPerf.TestReduceAnyPerf - TestAscendcApiPerf.TestReduceMaxPerf - TestAscendcApiPerf.TestReduceAllPerf - TestAscendcApiPerf.TestReduceMinPerf 这些 ST 用例补齐 output stride，确保 Reduce pattern 可被 parser 正确识别。 推荐命令： ```bash source ~/Ascend/cann/bin/setenv.bash bash scripts/test/run_autofuse_test.sh --st -j10 ``` #### 1.3 编译验证 ```bash source ~/Ascend/cann/bin/setenv.bash cd build make aihac_codegen -j10 ``` ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 See merge request: cann/graph-autofusion!4486 天前
solver_pass
add l Co-authored-by: JaydenChu<zhumin54@huawei.com> Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !370 merge 5_11_1 into master 【PR】: 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） Created-by: JaydenChu Commit-by: JaydenChu;xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） 所有涉及PR（包含检查过不需要同步的）从编号#1904（4.14 https://gitcode.com/cann/ge/pull/1904）到#2904（5.15 http://gitcode.com/cann/ge/pull/1904） 每个实际已同步pr都对应此pr的一个commit（部分同步pr为了方便同步合并到了一个commit中） ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 业务代码和llt编译通过 2. llt执行通过 3. 全量rdv验证通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!37015 天前
solver_pass_gen
【feat】: ATT支持多Group场景的CacheLine冲突建模 Co-authored-by: zhang_shengjie<804425610@qq.com> # message auto-generated for no-merge-commit merge: !440 merge feat/cache-line-conflict-detection into develop 【feat】: ATT支持多Group场景的CacheLine冲突建模 Created-by: zhang_shengjie Commit-by: zhang_shengjie Merged-by: cann-robot Description: # Pull Request ## 描述 ### 一、主要解决的问题 #### 1.1 Cache Line冲突导致性能建模不准确 在ATT Tiling代码生成的**组并行（group-parallel）**场景中，多个group并行执行时，perf建模原先采用统一的并行合并策略（GenPerfUpdateCode）：所有group的perf通过UpdateCurPerfAndBlockByGroup进行并行归并。 然而，当某些group的数据搬运的**单次搬运字节数小于硬件Cache Line大小**（如128字节）时，会产生**Cache Line冲突（false sharing）**。此时，这些group的实际执行性能不再是并行关系，而是**串行叠加**的。原有建模将冲突组perf按并行归并，导致性能评估偏高。 **影响范围**： - Load（GM→UB）和Store（UB→GM）两个方向均可能产生冲突 - 冲突组的perf应按**串行求和**而非**并行归并**计算 #### 1.2 CacheLineConfig缺少方向信息和表达式语义不精确 | 问题 | 描述 | |------|------| | CacheLineConfig缺少方向信息 | 无法区分GM→UB读操作和UB→GM写操作 | | 表达式语义不精确 | GetBlockCount使用总字节数而非单次搬运字节数 | | 无法区分两种表达式的用途 | 冲突检测需要单次搬运量，Solver需要总量，共用一个字段 | --- ### 二、修改方案 #### 2.1 CacheLineDirection枚举与CacheLineConfig扩展（model_info.h） 新增CacheLineDirection枚举： ```cpp enum class CacheLineDirection : uint8_t { kUnknown = 0, // 未知方向，不参与冲突检测 kGmToUb = 1, // GM→UB 读操作（Load） kUbToGm = 2, // UB→GM 写操作（Store） }; ``` 扩展CacheLineConfig结构体： | 字段/方法 | 说明 | |-----------|------| | direction | 数据搬运方向 | | solver_cache_line_expr | 总搬运字节数表达式（accumulate(dims) * dtype_size），编译期常量时为空 | | cache_line_expr | 含义收窄为单次搬运字节数（transfer_len * dtype_size） | | IsCacheLineConflictCandidate() | 判断是否需参与冲突检测（kGmToUb || kUbToGm，kUnknown返回false） | **关键设计**：将cache_line_expr（单次搬运量，用于冲突检测）和solver_cache_line_expr（总量，用于Solver UB约束）分离。 #### 2.2 Perf注册层重构（ascendc_api_perf_v2.cpp） 将GetBlockCount重构为AppendCacheLineConfig： | 维度 | 原实现 | 新实现 | |------|--------|--------| | 签名 | GetBlockCount(node_info, config) | AppendCacheLineConfig(node_info, direction, config) | | 表达式 | accumulate(dims) * dtype_size（总量） | 分离：transfer_len * dtype_size（单次）+ 总量 | | 方向 | 无 | 参数化传入 | 调用点：Load→kGmToUb，Store→kUbToGm，Nddma→kGmToUb。 #### 2.3 冲突检测Helper函数生成（tiling_code_gen_impl.cpp/h） 在tiling codegen阶段，为每个Group的每个tiling_case生成冲突检测lambda。 **新增6个方法**： | 方法 | 职责 | |------|------| | IsConflictCacheLineConfig | 静态辅助：判断CacheLineConfig是否需参与冲突检测 | | GenConflictGroupHelpers | 入口：遍历所有group，生成冲突检测lambda | | GenConflictGroupHelper | 为单个group的特定tiling_case生成冲突检测lambda | | GenConflictExprContextCode | 解析表达式中的自由符号，生成变量声明上下文 | | GenConflictGroupInvoke | 生成运行时switch-case分派代码 | | GenMixedPerfUpdateCode | 替换原GenPerfUpdateCode，实现混合perf聚合 | ##### GenConflictGroupHelper — 生成单个冲突检测Lambda 生成格式：IsConflictGroup_{asc_graph_id}_{impl_graph_id}_{group_id}_{tiling_case_id} **检测逻辑**： 1. **检查Schedule Table**：为空或未启用cache line检查 → fallback返回false 2. **过滤方向**：只处理IsConflictCacheLineConfig()为true的配置（即kGmToUb或kUbToGm，kUnknown被跳过） 3. **解析表达式符号**：调用GenConflictExprContextCode解析表达式中的自由变量 4. **冲突判定**：if (cache_line_expr < cfg_cache_line_size) return true;，其中cfg_cache_line_size优先使用自身值（> 0时），回退到ScheduleTable全局值 5. **异常处理**：无可有效配置 → fallback，表达式不可codegen → fallback ##### GenConflictExprContextCode — 符号解析 使用emit_decl lambda消除重复代码，按优先级查找符号来源： | 符号类型 | 数据源 | 判断方式 | |---------|--------|---------| | block_dim | tiling_data | 名称匹配 | | 硬件约束符号 | tiling_data | std::any_of遍历hardware_cons | | 容器/张量表达式 | group_tiling_data | count()查找 | | 输入变量 | group_tiling_data | ArgsManager获取input_vars | | axis列表变量 | group_tiling_data | std::any_of遍历arg_list | | 未知符号 | — | 返回{ "", false }触发fallback | 去重机制：declared_symbols set确保同一符号只声明一次。 ##### GenConflictGroupInvoke — 运行时分派 生成IIFE风格的switch-case，按final_tiling_key分发到对应helper。去重防护：重复key直接fallback。 ##### GenMixedPerfUpdateCode — 混合Perf聚合 ``` conflict_perf_sum = 0.0 normal_perf_merged = 0.0 for each group: if (is_conflict): conflict_perf_sum += perf // 冲突组：直接求和 else if (!has_normal_group): 初始化首个普通组 else: UpdateCurPerfAndBlockByGroup(...) // 后续普通组：并行归并 if (has_normal_group): normal_perf_merged += cur_tmp_perf cur_perf = conflict_perf_sum + normal_perf_merged ``` #### 2.4 Solver约束修正（axes_reorder_solver_gen.cpp） 使用solver_cache_line_expr（总量）替代cache_line_expr（单次量），并增加IsValid检查： ```cpp // 修正前: if (c.cache_line_size > 0) // 修正后: if (c.cache_line_size > 0 && IsValid(c.solver_cache_line_expr)) ``` --- ### 三、代码修改流程图 #### 3.1 文件依赖关系图 ```mermaid graph TD MI["model_info.h<br/>CacheLineDirection枚举<br/>CacheLineConfig扩展"] TCI_H["tiling_code_gen_impl.h<br/>6个新方法声明"] TCI_CPP["tiling_code_gen_impl.cpp<br/>冲突检测核心实现"] PERF["ascendc_api_perf_v2.cpp<br/>AppendCacheLineConfig重构"] SOLVER["axes_reorder_solver_gen.cpp<br/>solver_cache_line_expr"] STUB["stub_solver_model_info.h/cpp<br/>测试辅助类"] UT["att_generator_unittest.cpp<br/>11个单元测试"] ST["test_concat.cpp<br/>7输入concat基线场景"] PERF_UT["test_ascir_perf_v2.cpp<br/>Store CacheLine表达式测试"] MI --> TCI_CPP MI --> PERF MI --> SOLVER MI --> STUB TCI_H --> TCI_CPP PERF --> PERF_UT STUB --> UT style MI fill:#FFD700,stroke:#B8860B,stroke-width:2px style TCI_CPP fill:#FFD700,stroke:#B8860B,stroke-width:2px style PERF fill:#FFD700,stroke:#B8860B,stroke-width:2px style SOLVER fill:#FFD700,stroke:#B8860B,stroke-width:2px style STUB fill:#90EE90,stroke:#006400,stroke-width:2px style UT fill:#90EE90,stroke:#006400,stroke-width:2px style ST fill:#90EE90,stroke:#006400,stroke-width:2px style PERF_UT fill:#90EE90,stroke:#006400,stroke-width:2px ``` #### 3.2 冲突检测函数生成流程 ```mermaid flowchart TD Start([GenGetScheduleResult]) --> SecondTiling[二次Tiling生成] SecondTiling --> GenHelpers[GenConflictGroupHelpers] GenHelpers --> LoopGroups{遍历每个group} LoopGroups --> LoopCases{遍历每个model_info} LoopCases --> Dedup{tiling_case_id<br/>去重检查} Dedup -->|重复| Skip[跳过] Dedup -->|首次| CheckSchedule{检查Schedule Table} CheckSchedule -->|nullptr或未启用| Fallback1["OP_LOGD: unavailable<br/>return false"] CheckSchedule -->|已启用| FilterDirection{IsConflictCandidate?<br/>kGmToUb or kUbToGm} FilterDirection -->|kUnknown 跳过| Fallback2["OP_LOGD: no valid gm双向ub expr<br/>return false"] FilterDirection -->|有效方向| ResolveSymbols[GenConflictExprContextCode<br/>解析符号来源] ResolveSymbols -->|解析失败| Fallback3["OP_LOGD: not codegenable<br/>return false"] ResolveSymbols -->|解析成功| GenerateCheck["生成: if expr lt cfg_cache_line_size<br/>return true"] GenerateCheck --> LoopCases Fallback1 --> LoopCases Fallback2 --> LoopCases Fallback3 --> LoopCases Skip --> LoopCases LoopCases -->|所有case完成| LoopGroups LoopGroups -->|所有group完成| PerfCalc[perf计算和更新] PerfCalc --> CollectFlags[GenConflictGroupInvoke<br/>收集groups_conflict_flags] CollectFlags --> MixedPerf[GenMixedPerfUpdateCode<br/>混合聚合] style Start fill:#90EE90 style Fallback1 fill:#FF6347 style Fallback2 fill:#FF6347 style Fallback3 fill:#FF6347 style MixedPerf fill:#FF69B4,stroke:#C71585,stroke-width:2px ``` #### 3.3 混合性能聚合时序 ```mermaid sequenceDiagram participant CG as CodeGen participant RT as Runtime participant H0 as Helper Group0 participant H1 as Helper Group1 participant HN as Helper GroupN CG->>RT: 生成IsConflictGroup_x_x_0_0 lambda CG->>RT: 生成IsConflictGroup_x_x_1_1 lambda CG->>RT: 生成switch-case分发代码 RT->>RT: 遍历所有groups RT->>H0: 调用冲突检测 H0-->>RT: true (conflict) RT->>RT: conflict_perf_sum += perf0 RT->>H1: 调用冲突检测 H1-->>RT: false (normal) RT->>RT: cur_tmp_perf = perf1 (首个普通组) RT->>HN: 调用冲突检测 HN-->>RT: false (normal) RT->>RT: UpdateCurPerfAndBlockByGroup归并 RT->>RT: cur_perf = conflict_perf_sum + normal_perf_merged ``` --- ### 四、单元测试覆盖（11个代码生成UT + 1个Perf UT） | # | 测试名称 | 验证场景 | 预期行为 | |---|---------|---------|---------| | 1 | AllConflict_UseSumAggregation | 两个Group都有冲突 | 使用求和聚合，验证conflict_perf_sum和合并代码存在 | | 2 | BoundaryEqualCacheLine_StaysNormal | 表达式值恰好等于cache_line_size | 不判定为冲突（< 128返回false） | | 3 | FirstConflictSecondNormal_InitFromFirstNormal | Group0冲突，Group1正常 | 从第一个正常组初始化，验证has_normal_group逻辑 | | 4 | FinalTilingKeyDispatch_UsesFinalCaseHelper | 多case tiling key分发 | switch-case按case_id正确分发到对应helper | | 5 | ByteExprDoesNotMultiplyDtypeAgain | 字节表达式不应重复乘dtype_size | 验证生成的代码不包含dtype_size | | 6 | MissingScheduleTable_FallbackToNormalWithLog | Schedule Table为nullptr | fallback到正常组，验证日志输出 | | 7 | GmToUbConflict_UseSumAggregation | Group0为kGmToUb方向（Load冲突） | Load方向也触发冲突检测，使用求和聚合 | | 8 | DuplicateFinalKey_FallbackToNormalWithLog | 重复的tiling_case_id | 检测到重复key，验证日志输出 | | 9 | DynamicInputSizeSymbols_GenerateContext | 动态Shape符号（s1, s20） | 正确解析符号并生成context代码 | | 10 | UnknownDirection_FallbackToNormal | kUnknown方向 | fallback到正常组，验证日志输出 | | 11 | MultiWriteExprs_DeduplicateContext | 同group多个CacheLine配置共享符号 | 符号声明去重，CountSubstr == 1 | 另有一个Perf注册级别测试（test_ascir_perf_v2.cpp）：TestStoreApiCacheLineExprUsesSingleTransferLen，验证Store操作的cache_line_expr使用**最内层传输长度**而非全维度乘积。 --- ## 变更类型 - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新 - [x] ♻️ 重构（GenConflictExprContextCode重构） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue （待补充） ## 如何测试 ### 一 测试用例说明 #### 1.1 单元测试 运行ATT generator单元测试： ```bash # 冲突检测相关测试（11个用例） ./att_generator_unittest --gtest_filter="*CacheLine*" # API perf级别测试 ./utest_ascir_perf_v2 --gtest_filter="*CacheLineExpr*" ``` #### 1.2 系统测试 运行concat场景测试，验证七输入中轴concat的基线行为： ```bash # concat场景端到端测试 ./test_concat --gtest_filter="*SevenInputsMiddle*" ``` --- ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（feat:） - [x] 我已经详细阅读了贡献指南 ## 其他信息 ### 验证方法 1. 编译通过，所有新增单元测试通过 2. 生成的tiling代码中包含IsConflictGroup_*lambda函数 3. 冲突场景下perf计算使用求和策略，普通场景保持并行合并 4. 方向元数据正确传播：Load→kGmToUb, Store→kUbToGm 5. 双向冲突检测覆盖：kGmToUb和kUbToGm方向均参与检测 ### 注意事项 - CacheLineConfig的direction字段默认值为kUnknown，IsCacheLineConflictCandidate()对kUnknown返回false（不参与检测），确保向后兼容 - 每个CacheLineConfig可拥有独立的cache_line_size阈值（当> 0时使用自身值），否则回退到ScheduleTable全局值 - 重复tiling_key会被自动检测并fallback，不会导致运行时错误 - 动态Shape符号需要正确注册在model_info的sizes/tensor_exprs/container_exprs中才能被解析 - 冲突检测覆盖双向（GM→UB + UB→GM），仅kUnknown方向被排除 See merge request: cann/graph-autofusion!4408 天前
tiling_data_gen
add l Co-authored-by: JaydenChu<zhumin54@huawei.com> Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !370 merge 5_11_1 into master 【PR】: 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） Created-by: JaydenChu Commit-by: JaydenChu;xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） 所有涉及PR（包含检查过不需要同步的）从编号#1904（4.14 https://gitcode.com/cann/ge/pull/1904）到#2904（5.15 http://gitcode.com/cann/ge/pull/1904） 每个实际已同步pr都对应此pr的一个commit（部分同步pr为了方便同步合并到了一个commit中） ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 业务代码和llt编译通过 2. llt执行通过 3. 全量rdv验证通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!37015 天前
axes_reorder_tiling_code_gen_impl.cpp
add l Co-authored-by: JaydenChu<zhumin54@huawei.com> Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !370 merge 5_11_1 into master 【PR】: 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） Created-by: JaydenChu Commit-by: JaydenChu;xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） 所有涉及PR（包含检查过不需要同步的）从编号#1904（4.14 https://gitcode.com/cann/ge/pull/1904）到#2904（5.15 http://gitcode.com/cann/ge/pull/1904） 每个实际已同步pr都对应此pr的一个commit（部分同步pr为了方便同步合并到了一个commit中） ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 业务代码和llt编译通过 2. llt执行通过 3. 全量rdv验证通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!37015 天前
axes_reorder_tiling_code_gen_impl.h
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前
generator_config.h
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前
high_perf_tiling_code_gen_impl.cpp
add l Co-authored-by: JaydenChu<zhumin54@huawei.com> Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !370 merge 5_11_1 into master 【PR】: 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） Created-by: JaydenChu Commit-by: JaydenChu;xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 同步GE仓最新修改到AF仓（4.14上午11时~5.15晚，总计129个PR需要同步） 所有涉及PR（包含检查过不需要同步的）从编号#1904（4.14 https://gitcode.com/cann/ge/pull/1904）到#2904（5.15 http://gitcode.com/cann/ge/pull/1904） 每个实际已同步pr都对应此pr的一个commit（部分同步pr为了方便同步合并到了一个commit中） ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 业务代码和llt编译通过 2. llt执行通过 3. 全量rdv验证通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!37015 天前
high_perf_tiling_code_gen_impl.h
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前
tiling_code_gen_impl.cpp
【feat】: v35 ReduceMin/ReduceMax/ReduceAll/ReduceAny 三层性能建模实现 Co-authored-by: zhang_shengjie<804425610@qq.com> # message auto-generated for no-merge-commit merge: !448 merge fix_reduce_perf_model into develop 【feat】: v35 ReduceMin/ReduceMax/ReduceAll/ReduceAny 三层性能建模实现 Created-by: zhang_shengjie Commit-by: zhang_shengjie Merged-by: cann-robot Description: # Pull Request ## 描述 ### 一、主要解决的问题 #### 1.1 Reduce API 缺少 V2 性能建模入口 原有 V2 API perf 路径主要覆盖 elementwise、data move 和已有 RegBase 向量函数，ReduceMin/ReduceMax/ReduceAny/ReduceAll 缺少能感知 Reduce 语义的建模入口，无法区分： - AR 与 RA Reduce pattern - B64 与普通 dtype 的向量指令成本差异 - reuse source 与 non-reuse source 的拷贝路径差异 - multi-reduce 场景下 copy merge 与 elementwise merge 的尾部成本 #### 1.2 Reduce shape、stride、merge 语义没有统一载体 ATT parser 已经能拿到 input/output repeat、stride、loop axis 等信息，但后续 perf model 缺少结构化参数，只能在 ASCIR adapter 中临时推断。该分支把 Reduce 专用参数沉淀到 codegen::ReduceSpecificParams，让 parser、ASCIR adapter 和 AscendC API perf 共用同一套语义。 #### 1.3 性能公式缺少可读拆解 复杂 Reduce 公式生成后只落在 pipe_res 和 ternary 变量中，review 或定位 tiling case 时难以直接看出每段公式对应的建模分支。该分支新增 PerfBreakdownGroup / PerfBreakdownItem，并把 breakdown 传递到 tiling code annotation。 #### 1.4 测试覆盖不足 新增 Reduce perf model 覆盖面较大，涉及 Common 合轴、ASCIR 注册、RegBase、AscendC API、符号表达式和多 reduce merge，需要补充 UT/ST 覆盖。 ### 二、修改方案 #### 2.1 Common 层新增 Reduce 专用参数模型 autofuse/common/codegen_api_param/codegen_api_param.h/.cpp 新增： - ReducePattern: 区分 AR / RA - ReduceMergeMode: 区分 none、copy、elementwise merge - ReduceMergedDims: 保存归约后的 {first, last} 二维建模形态 - ReduceReuseInfo: 标记输入是否只被当前 reduce 使用 - ReduceSpecificParams: 汇总 reduce_type、pattern、merge_size、merge_times、reuse 等信息 - BuildReduceMergedAxisPlan / BuildReduceMergedShape / BuildReduceSpecificParams: 根据 repeat、stride、dtype size 生成统一 Reduce 建模参数 合轴逻辑以 input/output stride 是否为 0 判断 first/last 归属，并在需要时按 32B 对齐补齐尾轴尺寸。 #### 2.2 Parser 阶段填充 ReduceSpecificParams 新增 autofuse/att/gen_model_info/parser/reduce_specific_params_builder.cpp/.h，并在 AscendGraphParser::ConvertNodeInfos 中调用： - 识别 Max/Min/Mean/Prod/Sum/Any/All/ReduceMax/ReduceMin/ReduceAny/ReduceAll - 根据 output 最后一维 stride 是否为 0 推断 AR / RA - 根据 loop axis 与 input/output stride 关系判断是否需要 multi-reduce - 从 loop axis repeat 生成 merge_times - 通过输入 fanout 判断 reuse.is_reuse_source 同时 ParserSubAxis 保存 axis id，保证后续可通过 attrs.loop_axis_id 找到真实 loop axis。 #### 2.3 ASCIR Reduce adapter 负责上下文转换与注册分流 新增 autofuse/v35/att/api_perf_register/ascir_reduce_api_perf_v2.cpp/.h： - 将 codegen::ReduceSpecificParams 转成 ascendcapi_v2::ReduceApiPerfContext - 对当前 shape 重新构造 merged_dims，避免静态参数和实际 shape 不一致 - 对缺失 merged dims 的场景 fallback 到 last-axis merge - Max/Min/Any/All 在有 reduce params 时走 Reduce perf，无 reduce params 时保持 elementwise fallback - 注册 ReduceMax/ReduceMin/ReduceAny/ReduceAll 的 V2 perf 入口 #### 2.4 AscendC API 层新增 Reduce perf model 新增 autofuse/v35/att/api_perf_register/ascendc_api_perf/reduce_api_perf_v2.cpp/.h，核心入口为： - ReduceMinPerf - ReduceMaxPerf - ReduceAnyPerf - ReduceAllPerf 内部统一走 ReduceApiPerf，按 dtype、pattern、reuse、merge mode 分支： - logical reduce: Any/All - AR-B64 与 AR-normal - RA-B64 与 RA-normal - aligned / unaligned 子路径 - tree reduction 成本 - copy merge 与 elementwise merge 成本 - 256B vector block 与 B64 特殊 repeat 元素数 输出写入 perf.pipe_res[PipeType::AIV_VEC]，同时写入 perf.perf_breakdowns 供 tiling annotation 展示。 #### 2.5 RegBase 与 DataMove 路径整理 - ascendc_regbase_perf.cpp/.h 新增 ReduceMinPerf / ReduceMaxPerf，通过 VF 表统一计算 RegBase reduce min/max 成本 - B64 compare 分支抽成 CompareB64SpecificPerf - ascendc_api_perf_v2.cpp 中 DataMove 逻辑迁移到 ascendc_api_perf/data_move_api_perf_v2.cpp/.h #### 2.6 perf breakdown 贯穿生成链路 - autofuse/att/base/perf_breakdown.h: 新增 breakdown 数据结构 - ModelInfo: 保存 perf_breakdowns - PipePerfExpr: 从 API perf 输出收集 breakdown，并随变量替换更新表达式 - ArgsManager: 保存、替换和对外提供 breakdown - TilingCodeGenImpl: 在生成 tiling case annotation 时追加 Reduce perf breakdown ### 三、代码修改流程图 #### 3.1 多文件调用关系图 ```mermaid graph LR A[AscendGraphParser<br/>ConvertNodeInfos] -.-> B[Reduce params builder<br/>FillReduceSpecificParams] B -.-> C[Common params<br/>BuildReduceSpecificParams] C -.-> D[NodeInfo.reduce_specific_params] D -.-> E[ASCIR reduce adapter<br/>BuildReduceContext] E -.-> F[AscendC reduce perf model<br/>ReduceApiPerf] F -.-> G[PerfOutputInfo.pipe_res<br/>AIV_VEC] F -.-> H[PerfBreakdown<br/>semantic items] H -.-> I[PipePerfExpr and ArgsManager<br/>replace symbols] I -.-> J[Tiling code annotations<br/>case explanation] C -.-> K[Common UT<br/>merged shape] F -.-> L[Reduce perf UT<br/>AR RA B64 merge reuse] style B fill:#90EE90,stroke:#006400,stroke-width:2px style C fill:#90EE90,stroke:#006400,stroke-width:2px style E fill:#90EE90,stroke:#006400,stroke-width:2px style F fill:#90EE90,stroke:#006400,stroke-width:2px style H fill:#90EE90,stroke:#006400,stroke-width:2px style D fill:#FFD700,stroke:#B8860B,stroke-width:2px style J fill:#FFD700,stroke:#B8860B,stroke-width:2px ``` #### 3.2 ReduceApiPerf 分支流程图 ```mermaid flowchart TD S([ReduceApiPerf]) -.-> V[Validate context and dtype] V -.-> L{Logical reduce} L -.-> LG[Build logical reduce cost] L -.-> P{Reduce pattern} P -.-> ARD{AR B64 dtype} P -.-> RAD{RA B64 dtype} ARD -.-> ARB[Build AR B64 cost] ARD -.-> ARN[Build AR normal cost] RAD -.-> RAB[Build RA B64 tree cost] RAD -.-> RAN[Build RA normal tree cost] LG -.-> M{Merge mode} ARB -.-> M ARN -.-> M RAB -.-> M RAN -.-> M M -.-> O[Write AIV_VEC result] M -.-> CP[Add copy merge cost] M -.-> EW[Add elementwise merge cost] CP -.-> B[Append perf breakdown] EW -.-> B O -.-> B B -.-> R([Return ge.SUCCESS]) style S fill:#90EE90,stroke:#006400,stroke-width:2px style ARB fill:#FFD700,stroke:#B8860B,stroke-width:2px style ARN fill:#FFD700,stroke:#B8860B,stroke-width:2px style RAB fill:#FFD700,stroke:#B8860B,stroke-width:2px style RAN fill:#FFD700,stroke:#B8860B,stroke-width:2px style CP fill:#FF69B4,stroke:#C71585,stroke-width:2px style EW fill:#FF69B4,stroke:#C71585,stroke-width:2px ``` ## 变更类型 请选择本次引入的变更类型： - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 暂无。 ## 如何测试 ### 一 测试用例说明 #### 1.1 单元测试 重点覆盖： - CodegenApiParamReduceTest.*: BuildReduceSpecificParams、copy mode、invalid input、rank mismatch - UTestReduceMinMaxApiPerfV2.*: RegBase reduce min/max、AR/RA、B64、symbolic dim、reuse、multi-reduce merge、ASCIR 注册与 fallback - UTestAscirPerfV2.*: 既有 ASCIR V2 perf 路径回归 推荐命令： ```bash source ~/Ascend/cann/bin/setenv.bash bash scripts/test/run_autofuse_test.sh --ut -j10 ``` 已有构建产物时可定向执行： ```bash build/autofuse/tests/ut/att/att_ut --gtest_filter=UTestReduceMinMaxApiPerfV2.*:CodegenApiParamReduceTest.* ``` #### 1.2 系统测试 重点覆盖： - TestAscendcApiPerf.TestReduceAnyPerf - TestAscendcApiPerf.TestReduceMaxPerf - TestAscendcApiPerf.TestReduceAllPerf - TestAscendcApiPerf.TestReduceMinPerf 这些 ST 用例补齐 output stride，确保 Reduce pattern 可被 parser 正确识别。 推荐命令： ```bash source ~/Ascend/cann/bin/setenv.bash bash scripts/test/run_autofuse_test.sh --st -j10 ``` #### 1.3 编译验证 ```bash source ~/Ascend/cann/bin/setenv.bash cd build make aihac_codegen -j10 ``` ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 See merge request: cann/graph-autofusion!4486 天前
tiling_code_gen_impl.h
【feat】: ATT支持多Group场景的CacheLine冲突建模 Co-authored-by: zhang_shengjie<804425610@qq.com> # message auto-generated for no-merge-commit merge: !440 merge feat/cache-line-conflict-detection into develop 【feat】: ATT支持多Group场景的CacheLine冲突建模 Created-by: zhang_shengjie Commit-by: zhang_shengjie Merged-by: cann-robot Description: # Pull Request ## 描述 ### 一、主要解决的问题 #### 1.1 Cache Line冲突导致性能建模不准确 在ATT Tiling代码生成的**组并行（group-parallel）**场景中，多个group并行执行时，perf建模原先采用统一的并行合并策略（GenPerfUpdateCode）：所有group的perf通过UpdateCurPerfAndBlockByGroup进行并行归并。 然而，当某些group的数据搬运的**单次搬运字节数小于硬件Cache Line大小**（如128字节）时，会产生**Cache Line冲突（false sharing）**。此时，这些group的实际执行性能不再是并行关系，而是**串行叠加**的。原有建模将冲突组perf按并行归并，导致性能评估偏高。 **影响范围**： - Load（GM→UB）和Store（UB→GM）两个方向均可能产生冲突 - 冲突组的perf应按**串行求和**而非**并行归并**计算 #### 1.2 CacheLineConfig缺少方向信息和表达式语义不精确 | 问题 | 描述 | |------|------| | CacheLineConfig缺少方向信息 | 无法区分GM→UB读操作和UB→GM写操作 | | 表达式语义不精确 | GetBlockCount使用总字节数而非单次搬运字节数 | | 无法区分两种表达式的用途 | 冲突检测需要单次搬运量，Solver需要总量，共用一个字段 | --- ### 二、修改方案 #### 2.1 CacheLineDirection枚举与CacheLineConfig扩展（model_info.h） 新增CacheLineDirection枚举： ```cpp enum class CacheLineDirection : uint8_t { kUnknown = 0, // 未知方向，不参与冲突检测 kGmToUb = 1, // GM→UB 读操作（Load） kUbToGm = 2, // UB→GM 写操作（Store） }; ``` 扩展CacheLineConfig结构体： | 字段/方法 | 说明 | |-----------|------| | direction | 数据搬运方向 | | solver_cache_line_expr | 总搬运字节数表达式（accumulate(dims) * dtype_size），编译期常量时为空 | | cache_line_expr | 含义收窄为单次搬运字节数（transfer_len * dtype_size） | | IsCacheLineConflictCandidate() | 判断是否需参与冲突检测（kGmToUb || kUbToGm，kUnknown返回false） | **关键设计**：将cache_line_expr（单次搬运量，用于冲突检测）和solver_cache_line_expr（总量，用于Solver UB约束）分离。 #### 2.2 Perf注册层重构（ascendc_api_perf_v2.cpp） 将GetBlockCount重构为AppendCacheLineConfig： | 维度 | 原实现 | 新实现 | |------|--------|--------| | 签名 | GetBlockCount(node_info, config) | AppendCacheLineConfig(node_info, direction, config) | | 表达式 | accumulate(dims) * dtype_size（总量） | 分离：transfer_len * dtype_size（单次）+ 总量 | | 方向 | 无 | 参数化传入 | 调用点：Load→kGmToUb，Store→kUbToGm，Nddma→kGmToUb。 #### 2.3 冲突检测Helper函数生成（tiling_code_gen_impl.cpp/h） 在tiling codegen阶段，为每个Group的每个tiling_case生成冲突检测lambda。 **新增6个方法**： | 方法 | 职责 | |------|------| | IsConflictCacheLineConfig | 静态辅助：判断CacheLineConfig是否需参与冲突检测 | | GenConflictGroupHelpers | 入口：遍历所有group，生成冲突检测lambda | | GenConflictGroupHelper | 为单个group的特定tiling_case生成冲突检测lambda | | GenConflictExprContextCode | 解析表达式中的自由符号，生成变量声明上下文 | | GenConflictGroupInvoke | 生成运行时switch-case分派代码 | | GenMixedPerfUpdateCode | 替换原GenPerfUpdateCode，实现混合perf聚合 | ##### GenConflictGroupHelper — 生成单个冲突检测Lambda 生成格式：IsConflictGroup_{asc_graph_id}_{impl_graph_id}_{group_id}_{tiling_case_id} **检测逻辑**： 1. **检查Schedule Table**：为空或未启用cache line检查 → fallback返回false 2. **过滤方向**：只处理IsConflictCacheLineConfig()为true的配置（即kGmToUb或kUbToGm，kUnknown被跳过） 3. **解析表达式符号**：调用GenConflictExprContextCode解析表达式中的自由变量 4. **冲突判定**：if (cache_line_expr < cfg_cache_line_size) return true;，其中cfg_cache_line_size优先使用自身值（> 0时），回退到ScheduleTable全局值 5. **异常处理**：无可有效配置 → fallback，表达式不可codegen → fallback ##### GenConflictExprContextCode — 符号解析 使用emit_decl lambda消除重复代码，按优先级查找符号来源： | 符号类型 | 数据源 | 判断方式 | |---------|--------|---------| | block_dim | tiling_data | 名称匹配 | | 硬件约束符号 | tiling_data | std::any_of遍历hardware_cons | | 容器/张量表达式 | group_tiling_data | count()查找 | | 输入变量 | group_tiling_data | ArgsManager获取input_vars | | axis列表变量 | group_tiling_data | std::any_of遍历arg_list | | 未知符号 | — | 返回{ "", false }触发fallback | 去重机制：declared_symbols set确保同一符号只声明一次。 ##### GenConflictGroupInvoke — 运行时分派 生成IIFE风格的switch-case，按final_tiling_key分发到对应helper。去重防护：重复key直接fallback。 ##### GenMixedPerfUpdateCode — 混合Perf聚合 ``` conflict_perf_sum = 0.0 normal_perf_merged = 0.0 for each group: if (is_conflict): conflict_perf_sum += perf // 冲突组：直接求和 else if (!has_normal_group): 初始化首个普通组 else: UpdateCurPerfAndBlockByGroup(...) // 后续普通组：并行归并 if (has_normal_group): normal_perf_merged += cur_tmp_perf cur_perf = conflict_perf_sum + normal_perf_merged ``` #### 2.4 Solver约束修正（axes_reorder_solver_gen.cpp） 使用solver_cache_line_expr（总量）替代cache_line_expr（单次量），并增加IsValid检查： ```cpp // 修正前: if (c.cache_line_size > 0) // 修正后: if (c.cache_line_size > 0 && IsValid(c.solver_cache_line_expr)) ``` --- ### 三、代码修改流程图 #### 3.1 文件依赖关系图 ```mermaid graph TD MI["model_info.h<br/>CacheLineDirection枚举<br/>CacheLineConfig扩展"] TCI_H["tiling_code_gen_impl.h<br/>6个新方法声明"] TCI_CPP["tiling_code_gen_impl.cpp<br/>冲突检测核心实现"] PERF["ascendc_api_perf_v2.cpp<br/>AppendCacheLineConfig重构"] SOLVER["axes_reorder_solver_gen.cpp<br/>solver_cache_line_expr"] STUB["stub_solver_model_info.h/cpp<br/>测试辅助类"] UT["att_generator_unittest.cpp<br/>11个单元测试"] ST["test_concat.cpp<br/>7输入concat基线场景"] PERF_UT["test_ascir_perf_v2.cpp<br/>Store CacheLine表达式测试"] MI --> TCI_CPP MI --> PERF MI --> SOLVER MI --> STUB TCI_H --> TCI_CPP PERF --> PERF_UT STUB --> UT style MI fill:#FFD700,stroke:#B8860B,stroke-width:2px style TCI_CPP fill:#FFD700,stroke:#B8860B,stroke-width:2px style PERF fill:#FFD700,stroke:#B8860B,stroke-width:2px style SOLVER fill:#FFD700,stroke:#B8860B,stroke-width:2px style STUB fill:#90EE90,stroke:#006400,stroke-width:2px style UT fill:#90EE90,stroke:#006400,stroke-width:2px style ST fill:#90EE90,stroke:#006400,stroke-width:2px style PERF_UT fill:#90EE90,stroke:#006400,stroke-width:2px ``` #### 3.2 冲突检测函数生成流程 ```mermaid flowchart TD Start([GenGetScheduleResult]) --> SecondTiling[二次Tiling生成] SecondTiling --> GenHelpers[GenConflictGroupHelpers] GenHelpers --> LoopGroups{遍历每个group} LoopGroups --> LoopCases{遍历每个model_info} LoopCases --> Dedup{tiling_case_id<br/>去重检查} Dedup -->|重复| Skip[跳过] Dedup -->|首次| CheckSchedule{检查Schedule Table} CheckSchedule -->|nullptr或未启用| Fallback1["OP_LOGD: unavailable<br/>return false"] CheckSchedule -->|已启用| FilterDirection{IsConflictCandidate?<br/>kGmToUb or kUbToGm} FilterDirection -->|kUnknown 跳过| Fallback2["OP_LOGD: no valid gm双向ub expr<br/>return false"] FilterDirection -->|有效方向| ResolveSymbols[GenConflictExprContextCode<br/>解析符号来源] ResolveSymbols -->|解析失败| Fallback3["OP_LOGD: not codegenable<br/>return false"] ResolveSymbols -->|解析成功| GenerateCheck["生成: if expr lt cfg_cache_line_size<br/>return true"] GenerateCheck --> LoopCases Fallback1 --> LoopCases Fallback2 --> LoopCases Fallback3 --> LoopCases Skip --> LoopCases LoopCases -->|所有case完成| LoopGroups LoopGroups -->|所有group完成| PerfCalc[perf计算和更新] PerfCalc --> CollectFlags[GenConflictGroupInvoke<br/>收集groups_conflict_flags] CollectFlags --> MixedPerf[GenMixedPerfUpdateCode<br/>混合聚合] style Start fill:#90EE90 style Fallback1 fill:#FF6347 style Fallback2 fill:#FF6347 style Fallback3 fill:#FF6347 style MixedPerf fill:#FF69B4,stroke:#C71585,stroke-width:2px ``` #### 3.3 混合性能聚合时序 ```mermaid sequenceDiagram participant CG as CodeGen participant RT as Runtime participant H0 as Helper Group0 participant H1 as Helper Group1 participant HN as Helper GroupN CG->>RT: 生成IsConflictGroup_x_x_0_0 lambda CG->>RT: 生成IsConflictGroup_x_x_1_1 lambda CG->>RT: 生成switch-case分发代码 RT->>RT: 遍历所有groups RT->>H0: 调用冲突检测 H0-->>RT: true (conflict) RT->>RT: conflict_perf_sum += perf0 RT->>H1: 调用冲突检测 H1-->>RT: false (normal) RT->>RT: cur_tmp_perf = perf1 (首个普通组) RT->>HN: 调用冲突检测 HN-->>RT: false (normal) RT->>RT: UpdateCurPerfAndBlockByGroup归并 RT->>RT: cur_perf = conflict_perf_sum + normal_perf_merged ``` --- ### 四、单元测试覆盖（11个代码生成UT + 1个Perf UT） | # | 测试名称 | 验证场景 | 预期行为 | |---|---------|---------|---------| | 1 | AllConflict_UseSumAggregation | 两个Group都有冲突 | 使用求和聚合，验证conflict_perf_sum和合并代码存在 | | 2 | BoundaryEqualCacheLine_StaysNormal | 表达式值恰好等于cache_line_size | 不判定为冲突（< 128返回false） | | 3 | FirstConflictSecondNormal_InitFromFirstNormal | Group0冲突，Group1正常 | 从第一个正常组初始化，验证has_normal_group逻辑 | | 4 | FinalTilingKeyDispatch_UsesFinalCaseHelper | 多case tiling key分发 | switch-case按case_id正确分发到对应helper | | 5 | ByteExprDoesNotMultiplyDtypeAgain | 字节表达式不应重复乘dtype_size | 验证生成的代码不包含dtype_size | | 6 | MissingScheduleTable_FallbackToNormalWithLog | Schedule Table为nullptr | fallback到正常组，验证日志输出 | | 7 | GmToUbConflict_UseSumAggregation | Group0为kGmToUb方向（Load冲突） | Load方向也触发冲突检测，使用求和聚合 | | 8 | DuplicateFinalKey_FallbackToNormalWithLog | 重复的tiling_case_id | 检测到重复key，验证日志输出 | | 9 | DynamicInputSizeSymbols_GenerateContext | 动态Shape符号（s1, s20） | 正确解析符号并生成context代码 | | 10 | UnknownDirection_FallbackToNormal | kUnknown方向 | fallback到正常组，验证日志输出 | | 11 | MultiWriteExprs_DeduplicateContext | 同group多个CacheLine配置共享符号 | 符号声明去重，CountSubstr == 1 | 另有一个Perf注册级别测试（test_ascir_perf_v2.cpp）：TestStoreApiCacheLineExprUsesSingleTransferLen，验证Store操作的cache_line_expr使用**最内层传输长度**而非全维度乘积。 --- ## 变更类型 - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新 - [x] ♻️ 重构（GenConflictExprContextCode重构） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue （待补充） ## 如何测试 ### 一 测试用例说明 #### 1.1 单元测试 运行ATT generator单元测试： ```bash # 冲突检测相关测试（11个用例） ./att_generator_unittest --gtest_filter="*CacheLine*" # API perf级别测试 ./utest_ascir_perf_v2 --gtest_filter="*CacheLineExpr*" ``` #### 1.2 系统测试 运行concat场景测试，验证七输入中轴concat的基线行为： ```bash # concat场景端到端测试 ./test_concat --gtest_filter="*SevenInputsMiddle*" ``` --- ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（feat:） - [x] 我已经详细阅读了贡献指南 ## 其他信息 ### 验证方法 1. 编译通过，所有新增单元测试通过 2. 生成的tiling代码中包含IsConflictGroup_*lambda函数 3. 冲突场景下perf计算使用求和策略，普通场景保持并行合并 4. 方向元数据正确传播：Load→kGmToUb, Store→kUbToGm 5. 双向冲突检测覆盖：kGmToUb和kUbToGm方向均参与检测 ### 注意事项 - CacheLineConfig的direction字段默认值为kUnknown，IsCacheLineConflictCandidate()对kUnknown返回false（不参与检测），确保向后兼容 - 每个CacheLineConfig可拥有独立的cache_line_size阈值（当> 0时使用自身值），否则回退到ScheduleTable全局值 - 重复tiling_key会被自动检测并fallback，不会导致运行时错误 - 动态Shape符号需要正确注册在model_info的sizes/tensor_exprs/container_exprs中才能被解析 - 冲突检测覆盖双向（GM→UB + UB→GM），仅kUnknown方向被排除 See merge request: cann/graph-autofusion!4408 天前
tiling_code_generator.cpp
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前
tiling_code_generator.h
【PR】: [feat] [autofuse] joint debug with ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !349 merge master_joint_debug_with_ge into master 【PR】: [feat] [autofuse] joint debug with ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 1、修改autofuse后端代码，与ge仓的autofuse前端代码进行联调 2、修复硬编码以及非root用户卸载残留问题 3、适配工程禁用ASCEND_INSTALL_PATH的需求 4、新增cann包安装控制项，用于控制是否安装autofuse后端的编译产物(libaihac_codegen.so/libaihac_ir_register.so/libaihac_ir.so/pyautofuse.so等库) ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. graph-autofusion仓编译构建成功，出包验证安装卸载正常 2. 装包后autofuse红线用例验证通过 说明：此pr上库后装graph-autofusion的cann包默认是不会装autofuse产物的，故不会对现有的ge流程有影响，只有显示指定--autofuse安装选项才会安装autofuse产物，后续等ge仓代码要上库时此开关会同步放开。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!34922 天前