| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
【PR】: 将ut/st注册到ctest统一管理 Co-authored-by: 盛楠<titan.sheng@huawei.com> # message auto-generated for no-merge-commit merge: !1416 merge f_0722 into develop 【PR】: 将ut/st注册到ctest统一管理 Created-by: shengnan666 Commit-by: 盛楠 Merged-by: cann-robot Description: # Pull Request ## 描述 将ut/st注册到ctest统一管理 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!1416 | 2 个月前 | |
feat: 支持vectorfunc动态stride性能公式 Co-authored-by: gcw_V3YyYBt1<gaoxin32@huawei.com> # message auto-generated for no-merge-commit merge: !1208 merge develop into develop feat: 支持vectorfunc动态stride性能公式 Created-by: gcw_V3YyYBt1 Commit-by: gcw_V3YyYBt1 Merged-by: cann-robot Description: # Pull Request ## 描述 支持vectorfunc动态stride性能公式以及尾块计算 ## 问题原因 1. VectorFunc ATT 性能建模缺少结构化参数通路，double loop、stride、output dim 等信息无法通过统一的 AscirNodeParams 传递到 ATT parser 和性能公式，容易依赖散落属性并导致后续扩展困难。 2. VectorFunc double loop 场景下，stride 相等和不相等时的 micro api 次数计算方式不同；原有性能公式只按普通 dim product 计算，无法表达运行时 stride 是否相等带来的动态性能差异。 3. CheckSingleCut 尾块场景获取 tail perf 时直接走普通节点性能入口，VectorFunc 节点没有继续走 VectorFunc 专用性能公式，导致尾块性能计算路径不一致。 4. load store类型node没有计算到性能公式中。 ## 修改方案 1. 新增 ascir_param::VectorFuncNodeParams，将 is_double_loop、all_strides、output_dims 作为 VectorFunc 专用 typed params，并纳入 AnySpecificParams。 2. EnrichAscirNodeParams 对 VectorFunc 预注册 AscirNodeParams，codegen 阶段通过 GetAscirNodeParams 更新已有参数，避免新增独立 ExtAttr 或散落 vf_* 字段。 3. VectorFunc codegen 在 double loop 场景收集实际 stride 表达式和尾部 output dims；生成 strides_equal 判断代码的同时，将 stride 表达式同步写入 VectorFuncNodeParams。 4. ATT parser 从 AscirNodeParams 读取 VectorFuncNodeParams 并写入 NodeInfo，PipePerfExpr 调用 VfPerfUtils::GetVectorFunctionPerf 时传入 typed params 和 ternary_ops。 5. VfPerfUtils 根据 VectorFuncNodeParams 区分非 double loop、stride 确定相等、stride 确定不等和动态 stride 场景；动态场景生成 vf_dynamic_perf TernaryOp，在运行时按 all_strides 是否相等选择性能公式。 6. CheckSingleCut tail perf 改为通过 GetNodePerfInternal(..., tail_shape=true) 进入，使 VectorFunc tail 场景仍走 VectorFunc 专用性能公式，普通节点继续透传 tail_shape 到 GetNodePerf。 7. 补充 AscirNodeParams UT，覆盖 VectorFuncNodeParams 存储和 EnrichGraph 预注册 VectorFunc 参数。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue ## 如何测试 描述测试此变更的步骤和前提条件： 1.测试vectorfunc相关用例，双切分与单切分场景，有尾块与没有尾块场景 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 See merge request: cann/graph-autofusion!1208 | 3 个月前 | |
style: 统一 Autofuse 代码格式 Co-authored-by: Ling-DT<lingxing@huawei.com> # message auto-generated for no-merge-commit merge: !921 merge style/clang-format-autofuse-20260611 into develop style: 统一 Autofuse 代码格式 Created-by: ling-DT Commit-by: Ling-DT Merged-by: cann-robot Description: # Pull Request ## 描述 基于 cann/graph-autofusion:develop 最新提交 46a23b0，使用仓库根目录 .clang-format 对 autofuse/ 目录内受版本管理的 C/C++/AscendC 源文件执行统一格式化。 本 PR 仅包含 autofuse/ 目录格式化变更；super_kernel/ 目录格式化变更按要求暂留本地，未提交到本 PR。 格式化工具：clang-format 18.1.8，参数：--style=file。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无。 ## 如何测试 描述测试此变更的步骤和前提条件： 1. /tmp/opencode/clang-format-18-venv/bin/clang-format -i --style=file <autofuse C/C++/AscendC files> 2. git diff --cached --check 3. git diff --name-only HEAD~1..HEAD | cut -d/ -f1 | sort | uniq -c 确认 PR 提交仅包含 autofuse/。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本 PR 为纯格式化变更，不涉及功能逻辑、接口、构建脚本或打包内容修改。 See merge request: cann/graph-autofusion!921 | 3 个月前 | |
perf: 完善 Autofuse V2 Broadcast 性能建模(#235) Co-authored-by: hamburgerbobo<gaoyubo4@huawei.com> # message auto-generated for no-merge-commit merge: !2074 merge perf/broadcast-v2-warn-divzero into develop perf: 完善 Autofuse V2 Broadcast 性能建模(#235) Created-by: hamburgerbobo Commit-by: hamburgerbobo Merged-by: cann-robot Description: # Pull Request ## 描述 重新提交 PR #1812 的内容（原 PR 被回退），并在此基础上将 Broadcast perf 建模中的除零错误检查从 ERROR 级别（GE_ASSERT_TRUE -> GELOGE）降级为 WARNING 级别（GE_WARN_ASSERT -> GELOGW），避免除零检查失败时输出 ERROR 日志。 原pr链接：https://gitcode.com/cann/graph-autofusion/pull/1812 具体变更： 1. 完整恢复 PR #1812 的 23 个文件（Broadcast V2 性能建模全套实现和测试） 2. 将 3 个 perf 文件中 8 处除零检查从 GE_ASSERT_TRUE 替换为其他告警： - broadcast_perf_utils_v2.cpp：4 处（byte_size / divisor / half_vl 检查） - broadcast_last_axis_perf_v2.cpp：3 处（SafeDiv divisor / E2B last_size / GatherTwo last_size） - broadcast_nlast_axis_perf_v2.cpp：1 处（SafeDiv divisor） ## 变更类型 - [x] ✨ 新功能 ## 关联的Issue #235 ## 如何测试 1. sh build.sh -u --module=autofuse_framework -j 8 2. 运行 Broadcast perf V2 相关 UT ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本 PR 替代被回退的 PR #1812，内容一致但除零检查改为 WARNING 级别。 See merge request: cann/graph-autofusion!2074 | 1 个月前 | |
【PR】: [fix] [autofuse] adapt reform of the same-named header files of ge. Co-authored-by: xingzhixiong<xingzhixiong@huawei.com> # message auto-generated for no-merge-commit merge: !1149 merge develop_change_dir_of_metadef_headers into develop 【PR】: [fix] [autofuse] adapt reform of the same-named header files of ge. Created-by: xingzhixiong Commit-by: xingzhixiong Merged-by: cann-robot Description: # Pull Request ## 描述 metadef在做同名头文件整改，整改完编译发现gaf失败，原因是gaf仓和ge仓也有同名且子目录相同的头文件，故需要将gaf仓的同名头文件的子目录进行整改，只给gaf仓内部使用，避免产生耦合编译问题。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. ci流水线pass 2. RDV pass ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!1149 | 3 个月前 | |
【PR】: autofuse支持extendconv2d Co-authored-by: linchujia525<1165980433@qq.com> # message auto-generated for no-merge-commit merge: !1669 merge develop into develop 【PR】: autofuse支持extendconv2d Created-by: weixin_45675704 Commit-by: linchujia525 Merged-by: cann-robot Description: # Pull Request ## 描述 autofuse原有支持Conv2DV2的自动融合，现新增对ExtendConv2D自动融合的支持。 主要变更： - ASCIR 算子：在 v1/v2 注册 ExtendConv2D / ExtendConv2DBias / ExtendConv2DScale / ExtendConv2DBiasScale，补充 round_mode、enable_relu0、fixed_shift_value 等 IR 属性；GE bridge 识别这些类型。 - 属性与构图工具：ParseConv2DAttr / IsConv2DGraphType 覆盖 extend 及可选 bias、offset_w、scale0；GetCubeAttributes 向外导出 is_extend_conv2d、has_scale0、round_mode 等字段。 - Codegen / Kernel：conv2d_v2 对齐 ActConvConfig 模板维（含 BatchOne、SmallKernel），增加 scaleGM 槽位；Cube tiling 与 CV fusion 向量侧支持 extend 场景（含 tmpTilingData.nL0）。顺带拆分 cube tiling 超大函数，满足规范。 - Host 编译：ConvArgsConfig 区分 Conv2DV2 紧凑入参和 ExtendConv2D 的 10 槽逻辑输入（未连接的 bias/scale 填空）。 - TilingKey：更新 conv2d_v2_tilingkey_cv.h，与新模板维一致。 - 测试：补充 UT/ST，覆盖属性解析、codegen tiling、Python cube attributes、compile 入参槽位和 backend e2e 构图。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!1669 | 1 个月前 | |
feat: 支持Gather后置Norm复合区域识别与融合调度（含SIMT side-input视图适配） Co-authored-by: JaydenChu<zhumin54@huawei.com> # message auto-generated for no-merge-commit merge: !2329 merge reapply/pr-2064-gather-norm into develop feat: 支持Gather后置Norm复合区域识别与融合调度（含SIMT side-input视图适配） Created-by: JaydenChu Commit-by: JaydenChu Merged-by: cann-robot Description: ## 描述 在 IndirectLoad 候选生成链路中支持 Gather 后置 Norm 复合区域（Softmax / LayerNorm 等多个 Reduce + Broadcast + Elementwise 组合）的识别、校验与调度接入，打通 Softmax 专用/通用双路径分流；同时适配 SIMT body 内行级广播 side-input 的坐标重建。 ### 问题场景 含 IndirectLoad 的图后接 Norm 类计算时，现有 Gather+Reduce 候选链存在四类问题： 1. **Gather+Softmax 候选被误杀**：SoftmaxApiCall::Generate 固定把最后一个向量化轴当作 R，且专用 Softmax 节点保持完整输入输出形状；普通 Reduce 的 stride 推导对它推不出归约轴，导致候选在布局校验阶段被淘汰。 2. **多 Reduce 图断言失败**：CollectOutputBoundaries 遇到第二个 Reduce 时触发图级断言，LayerNorm 均值/方差双分支形态直接编译失败。 3. **SIMT body 内行级广播 side-input 编译失败**：带 arange/matmul 的图，softmax 复合区域的行级广播 side-input Load（如 [8,2048,1]/strides=[2048,1,0]，每行读一个向量沿尾轴广播）经调度期视图 split 改写后 rank 失配且尺寸符号化，坐标重建断言失败。 4. **IL 模板 merge 后 vectorized_axis 不一致**：tensor merge 只折叠 axis/repeats/strides 不处理 vectorized_axis，中间窗口公共检查打误导性 ERROR。 ### 问题原因 - 现有 RewrittenGraphAnalysis::post_reduce 为单 Reduce 假设，无法表达多统计 Reduce 区域 - Softmax Pattern 替换依赖 ReducePartitionCaseGenerator 的 AllLoad 流程，遇 IndirectLoad 提前返回 - SIMT body 是静态成员函数（无 tiling data 参数），坐标重建要求编译期常量，视图 split 符号化后兜底失效 - tensor merge 与 vectorized_axis remap 分两步执行，中间窗口视图自洽性缺失 ### 修改方案 **复合区域识别与调度**： 1. 新增 norm_utils：NormInfo/NormStage 元数据，基于节点 ExtAttr 随候选图复制传递 2. 抽取 softmax_pattern_fusion_utils：MatchStableStructure/MatchStableDedicated 拆分匹配 3. CollectOutputBoundaries 收集全部 Reduce，逐个校验同轴 Broadcast 配对 4. SIMD 逐 Reduce 独立校验（ValidateSimdCompositeLayouts）；SIMT 串行多阶段 5. simt_boundary_sync：SIMT 边界视图 split 同步与 vectorized_axis 两级重映射 6. SIMD padded 视图强制 strided 降级（按视图 strides 逐行写，行内 pad 由 ReduceInit 清中性值） **SIMT side-input 视图适配**： 7. SimtLoadMetadata 增加行级广播标记：generator 在视图改写前按原始结构判定（尾轴 stride==0、其余轴 row-major 稠密递推——从后往前），写入节点 attr 穿透 VF 克隆 8. codegen 坐标重建兜底：rank mismatch 断言前按 output_index / 尾轴宽 去尾维寻址（读[行,列]值沿尾轴广播的正确语义） 9. IL 模板 tensor merge 后，vectorized_axis 中失效旧轴立即替换为 merged 轴（消除中间窗口不一致，RemapOutputVectorizedAxes 的 direct_ancestor 路径无缝衔接到 inner 轴） ### 修改效果 - Gather+Softmax（专用 API）、Gather+LayerNorm（多 Reduce 共享输入）、Gather+串行多阶段均进入正常调度链 - 行级广播 side-input（含带 arange/matmul 图）正确寻址 - SIMD padded 视图降级 strided，消除 index 越界读 - 全部失败路径候选级淘汰并记录日志（原为图级断言失败） - 原有单 Reduce、无 Reduce、SIMD 模板场景行为不变 - 未侵入通用 ScheduleTask 结构 ## 变更类型 - [x] ✨ New feature - [x] 🐛 Bug fix ## 关联的Issue 无 ## 如何测试 1. 已执行：codegen 全量 55/55、optimize_ut 734、optimize_st 213 全部通过 2. 已验证：行级广播兜底（标记/递推/寻址）各环节形态断言通过 3. 待执行：生产带 arange/matmul 图复测 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对功能进行了自测（全量回归+形态断言） - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了适当的类型标签（feat:） - [x] 我已仔细阅读贡献指南（CONTRIBUTING.md）并遵循所有规则 See merge request: cann/graph-autofusion!2329 | 26 天前 | |
feat: add SoC-specific ATT performance model Co-authored-by: zhang_shengjie<804425610@qq.com> # message auto-generated for no-merge-commit merge: !2490 merge feat/att-soc-perf-model-lite into develop feat: add SoC-specific ATT performance model Created-by: zhang_shengjie Commit-by: zhang_shengjie Merged-by: cann-robot Description: ## 描述 ### 一、主要解决的问题 #### 1.1 V35 需要同时携带 NpuArch 与完整 SoC 原有 PlatformInfo.soc_ver 承担 NpuArch 语义，V35 无法区分同一架构下的具体 SoC。本次保留旧字段和旧接口布局，新增内部完整 SoC 状态与 SetPlatformTarget/GetPlatformTarget，Python set_platform 增加可选第四个位置参数。 #### 1.2 历史性能模型需要按完整 SoC 做少量差异合成 新增 SoC 性能配置核心，按 (NpuArch, full_soc_version) 精确绑定目标，复用历史 JSON 基线并合成显式差异；校验成功后才发布只读缓存，避免目标间参数串用。 #### 1.3 ASCIR / AscendC 需要稀疏函数替换 包装层读取同一目标副本，先按原工厂注册名创建对象，再按注册名解析 ASCIR / AscendC 覆盖。空覆盖保留原函数；显式覆盖的源项或目的函数不存在时失败，不回退到默认函数，也不叠加成本。 #### 1.4 公开入口需要提前失败并正确传播异常 ATT 建模、公开 codegen 和 Python backend 在进入 PGO / 图处理前校验目标；公式失败不提交节点成本；Python codegen 的 runtime_error 转为 Python 异常，不再返回部分 host 结果。 #### 1.5 既有 V35 测试夹具需要显式完整 SoC 为进入新路径的旧夹具统一安装 V35 测试平台，保留原基线成本语义，避免只设置 3510 后因缺少完整 SoC 而误报。 #### 1.6 配置缓存需要避免临时对象地址复用并降低重复解析成本 临时配置不持久缓存，避免地址复用误命中；内置表缓存校验和合成结果，后续函数解析只查当前 API。机制和验证见软件设计 3。 ### 二、修改方案 1. 平台双维度状态沿用原锁和布局；旧 setter 清理完整名称，新 setter 同步 UB override。 2. Python 查询 requires_full_soc_version，仅 V35 取完整 SoC，一次设置平台。 3. soc_perf_config 负责目标校验、JSON 合成、只读缓存和两类覆盖解析。 4. 旧性能入口使用目标副本；ASCIR 类型名与工厂注册名区分。 5. ATT/codegen 提前校验，Python 接收状态失败和异常。 6. UT/ST 扩展原夹具，V35 E2E 使用 InstallV35SocPerfRuntimeStub。 7. 固定配置缓存校验及合成结果；临时配置不持久缓存，函数解析只查当前 API。 各项数据结构、接口和边界见下文软件设计 1–3。 ### 三、代码修改流程图 mermaid graph TD A[Python 或 C++ 入口] -->|target| B[读取双维度目标] B -->|query| C{是否需要完整 SoC} C -->|No| D[原 V2 路径] C -->|Yes| E[校验目标与配置] E -->|Invalid| X[生成前失败] E -->|Valid| F[合成历史 JSON 参数] F -->|resolve| G[解析 API 覆盖] G -->|generate| H[建模与代码生成] H -->|Error| Y[传播错误] H -->|Success| Z[返回完整结果] ### 四、lite 设计：需求 1–3 与软件设计关联 #### 4.1 设计目的、范围及约束 复用历史 JSON 和原工厂/函数注册表，不新增 profile 身份、版本或 variant 注册层。 范围为 JSON 系数、API 函数覆盖和错误接收；VF、头成本、NDDMA / RegBase 沿用基线。真实模型、大量标定、新 schema 和调度差异另评估。不改图/pass 或 SuperKernel 接口，参数变化可能影响 tiling。 完整请求串行执行，期间目标固定。原子设置不等于整链并发安全；旧公式再次进入包装仍重新读取目标，不承诺整批只读一次或跨目标并发建模。 | 功能需求 | 软件设计及接口 | 验证关联 | |----------|----------------|----------| | 需求 1：双维度目标选择参数 | SetPlatformTarget、ReadSocPerfTarget、ValidateSocPerfConfig、GetSocApiParams | 同架构 A/B 参数、V2 原路径、缺目标/绑定失败 | | 需求 2：少量 API 覆盖模型 | ResolveSocAscIrPerf、ResolveSocAscendCPerf | 空覆盖等价、替代只调用一次、注册名/别名、显式缺失失败 | | 需求 3：历史参数同源与基本隔离 | 原参数 getter、目标缓存、旧 setter / Reset | 原表不变、输入字段拒绝、显式目标隔离、串行 A/B/A、地址复用 | #### 4.2 软件设计 1：双维度目标选择参数（关联需求 1） cpp struct SocPerfTarget { std::string npu_arch; std::string soc_version; }; using SocPerfKey = std::pair<std::string, std::string>; // NpuArch、完整 SoC version。 struct SocPerfConfig { Json api_param_overrides = Json::object(); std::map<std::string, std::string> ascir_model_overrides; std::map<std::string, std::string> ascendc_model_overrides; }; using SocPerfConfigs = std::map<SocPerfKey, SocPerfConfig>; SocPerfKey 是 NpuArch 与完整 SoC 的精确键，不是 profile key。配置随库交付、只读使用，不按前缀推断或解析 ini。架构形态沿用原登记：2201 使用 V2，3510 / 5102 / 9201 / 9202 使用 V35，未登记的 3102 不新增支持。架构登记与正式完整 SoC 绑定是两个独立条件。 Python 从同一 CANN 编译目标取 NpuArch，通过只读 requires_full_soc_version 判定；仅 V35 再取 SOC_VERSION，一次设置平台。C++ 显式设置二者。旧 PlatformInfo.soc_ver 保留 NpuArch 语义和原布局，完整 SoC 存储在 cpp 内部、沿用原锁。 平台接口为 SetPlatformTarget(platform_info, soc_version) / GetPlatformTarget(npu_arch, soc_version)；核心接口为 ReadSocPerfTarget、ValidateSocPerfConfig、GetSocApiParams，返回 af::Status。Python setter 的可选第四参数是完整 SoC。 旧 set_platform 三参数顺序不变；旧 setter / Reset 清除完整 SoC，新 setter 同步 UB override。包装经 ReadSocPerfTarget 取得本次副本，核心显式接收目标，不从平台补字段。V35 按副本的 NpuArch 查询 AscirRegistry 和原工厂定位基线，避免目标 A 使用平台 B 的参数。 mermaid flowchart TD A[同一编译目标的 NpuArch 与完整 SoC] -->|一次设置| B[PlatformContext 双维度目标] B -->|包装读取副本| C{查询原架构登记} C -->|V2| D[原 V2 路径] C -->|V35| E{精确绑定并获取已校验配置} C -->|未登记| X[返回失败] E -->|缺名称 缺绑定 或非法配置| X E -->|成功| F[同架构历史 JSON 与目标差异] F -->|参数缓存| G[GetPerf 沿用原公式] #### 4.3 软件设计 2：少量 API 覆盖模型（关联需求 2） | 配置字段 | key | value | 未配置覆盖时 | |----------|-----|-------|--------------| | ascir_model_overrides | 原工厂规范化 API 注册名，如 AbsV2 | EvalCosts 已登记的 Perf key | 原 ASCIR 函数 | | ascendc_model_overrides | 原 GetAscendCPerfFunc 注册名，如 LoadV2 | EvalCosts 已登记的 AscendCPerf key | 原 AscendC 函数 | 两类映射独立，保留别名和架构 tag，不把 SoC 拼进 API 名称。GetApiPerf 按显式架构创建原对象，以 GetApiName() 选择覆盖；只替换 Perf，原参数表、MicroPerf 和调度表指针不变。 ResolveSocAscIrPerf / ResolveSocAscendCPerf 以 target、API 注册名和默认函数为输入，输出所选函数，返回 af::Status。 default_func 来自同一目标，输出沿用 Perf / AscendCPerf。覆盖只选择一个已登记函数，不累计默认成本；显式关联不存在则失败。AscendC 覆盖只作用于经过 GetAscendCPerfFunc 的调用。原 GetPerfFunc 保持静态查询，注册阶段不读取平台。 mermaid flowchart TD A[显式目标与规范化 API 注册名] -->|读取| B[已校验的内置配置] B -->|仅查当前 API| C{是否配置覆盖} C -->|否| D[同目标原函数] C -->|是| E{原始 EvalCosts 查询替代函数} E -->|缺失| X[返回失败 禁止默认兜底] E -->|成功| F[替代函数] D -->|执行| G[只调用所选函数一次] F -->|执行| G #### 4.4 软件设计 3：历史参数同源与基本隔离（关联需求 3） 历史 JSON 是参数基线层：原 perf_param 中的 kParamV2Info 原位保留，原 getter 仍返回历史表；本方案没有替代它或复制一份新参数源码。 text 原 perf_param / kParamV2Info（历史基线） + SocPerfConfig.api_param_overrides（SoC 稀疏差异） -> 校验及合成 -> 共享 const JSON -> 原 GetPerf / 公式 ##### 新增 MCXXXX 的 API 系数适配规则 1. 先确认 MCXXXX 的真实 NpuArch，并确认该架构已登记为 V35；不能按型号前缀推断。未知架构需要先接入架构实现，只有 SoC 参数绑定不够。 2. 在 soc_perf_config.cpp 的 GetBuiltinSocPerfConfigs 生产分支，构造 SocPerfConfig 并以 (NpuArch, MCXXXX) 登记。参数结构为 API -> model_params -> dtype pair -> 完整系数记录；参数 key 使用历史 JSON 名称 Abs，不是函数覆盖注册名 AbsV2。 3. 每条 dtype 记录提供完整系数；即使只调整 k，仍需提供 b。API、dtype 和字段必须存在于基线；不得改 model_type，拒绝 data_type_size / block_count_idx。实际 float 范围及必要除数非零校验沿用现有逻辑，负系数按公式语义处理。 4. 未覆盖 API/dtype 沿用历史参数，原 dtype fallback 和 EnrichParamMapForModel 不变。仅系数变化时两类模型覆盖映射保持为空，原公式和 kParamV2Info 不修改。 假设已确认 MCXXXX 属于 5102，生产配置构造阶段的登记示例如下；数值仅演示，需替换为真实标定值： cpp SocPerfConfigs result; SocPerfConfig mc_config; mc_config.api_param_overrides["Abs"]["model_params"]["float16tofloat16"] = {{"k", 0.01F}, {"b", 22.0F}}; result.emplace(SocPerfKey{"5102", "MCXXXX"}, std::move(mc_config)); 正常 Python 编译自动读取完整目标；手动调用时设置二者： python ascir.utils.set_platform("5102", vector_core_num, ub_size, "MCXXXX") 配置随库交付，修改后重新构建。UT/ST 验证新系数生效、未覆盖参数保持基线、默认函数不变及非法记录拒绝。测试宏使用独立配置表，公共入口测试需同步测试绑定；核心可显式注入配置。新增 SoC 的真实系数精度另做标定/RDV，不属于下文已有测试结果。 内置配置按 SocPerfKey 缓存成功校验、配置副本、历史 JSON 与合成参数；首次校验与合成复用解析结果，后续入口直接命中。空差异共享解析基线，非空差异生成独立只读参数；失败不发布目标缓存。临时显式测试配置不持久缓存，避免对象地址复用。 mermaid flowchart TD A[显式目标与同架构历史 JSON] -->|查内置目标| B{成功资源缓存命中} B -->|是| C[共享只读参数] B -->|否| D[校验绑定 系数及模型覆盖] D -->|失败| X[返回失败 不发布目标缓存] D -->|成功| E[复用基线解析结果并合成差异] E -->|成功后发布| C C -->|求值| F[原 dtype fallback 输入增强及公式] 缓存有界，不持有 Expr、设备句柄或跨 SO 回调；核心不读取平台。 #### 4.5 错误、兼容性与后续迁移 缺完整名称、未知架构、未登记 SoC、非法系数或显式模型缺失，在公开 codegen / ATT 入口提前失败，不跨 V2 / V35 回退。V35 公式失败不提交节点成本，Python 转为异常；历史 PGO 重试规则保留，重试目标与模型不变。 V2 原路径、历史 JSON、ApiPerf / ModelInfo / Codegen / TilingLib 旧布局和签名保持；有效 V35 空差异绑定默认成本等价，仅架构 V35 调用需补齐目标。沿用既有打包规则，测试资源不进入正式包。测试及交付证据见下文；合成测试不代表芯片精度，真实差异需 source/codegen 对照与 RDV。 完整方案复用目标、绑定、稀疏映射、显式核心和 UT/ST，再扩展 context、typed 参数、全成本域、平台快照与完整错误协议。原完整版设计和计划保留，不声明 lite 已实现完整方案。 ## 变更类型 - [x] Bug 修复 - [x] 新功能 - [ ] 代码风格更新 - [ ] 重构 - [x] 构建过程或辅助工具的变动 - [ ] 文档内容更新 ## 关联的Issue 无 ## 如何测试 ### 一、测试用例说明 #### 1.1 单元测试 - C1 common UT：通过。 - C2 ATT UT：通过，1340 个用例运行、1 个禁用；新增 SocPerfConfigTest 36/36 通过。 - C3 codegen / py_module UT：通过；Python 汇总 275 passed / 5 skipped。 - C4 test_asc_codegen_compile_soc_target.py：5/5 通过。 - 平台上下文、入口校验、公式失败、异常路径、float 溢出 / 零除数、注册名与别名场景均有定向用例。 #### 1.2 系统测试 - C5 ATT ST：1/1 通过，包含 115 个 gTest 用例。 - C6 autofuse_framework：通过，test_main 与 Python 276 passed / 5 skipped。 - C7 autofuse_e2e：通过，四阶段分别为 49/49、82/82、49/49、82/82。 - C8 正常打包：通过，生成 cann-graph-autofusion_9.2.0_linux-x86_64.run。 - C9 no-autofuse 打包：通过；包内仅含 SuperKernel 产物，不含 Autofuse 后端与测试资源。 ### 二、性能验证 默认目标建模耗时约 13–14 ms/次，重复执行结果稳定；成功参数由共享只读缓存复用，核心接口不读取当前平台，默认路径无节点级 runtime 查询。内置目标校验与合成结果按目标缓存，后续函数解析仅查询当前 API 覆盖项。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签 - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md） ## 其他信息 ### 验证方法 使用本地 CANN 与 third_party 依赖执行计划中的 C1–C9，全部通过。交付包内容已核对：正常包包含 aihac_codegen、pyautofuse 与 Python 脚本；no-autofuse 包不包含 Autofuse 后端；两种包均不包含测试宏、测试配置或测试 tiling 库。 ### 注意事项 - 正式完整 SoC 绑定清单尚未确认。本地仅有 MC62CM12AA -> 5102 证据，生产内置绑定表目前为空；生产 V35 请求会因缺少绑定提前失败，需确认首期清单并登记后才能正式启用。本地证据不自动视为交付授权。 - 测试宏只切换测试资源来源，不改变校验、公式或错误行为；正式 aihac_codegen 不包含 ATT_SOC_PERF_CONFIG_TEST。 - pyautofuse_runtime_error_tiling 仅用于测试构建，不进入正式交付包。 ### 提交记录 | Commit | 描述 | 修改文件数 | |--------|------|-----------| | bf6c6cab0 | feat: add SoC-specific ATT performance model | 214 | | 6038ef6a5 | fix: harden SoC perf config cache | 2 | ### 修改文件清单 整体规模：214 个文件，2488 行新增，407 行删除。其中生产代码 14 个文件约 839 行新增 / 38 行删除，测试与构建 200 个文件约 1649 行新增 / 369 行删除。 lite 原预算为生产与测试合计 760–1000 行，文档不计入；实际新增/删除合计 2895 行，已超原预算。生产代码约 877 行不代表整体达成 1000 行目标，预算验收仍需范围复核。 | 文件路径 | 修改类型 | 说明 | |---------|---------|------| | autofuse/common/platform_context.cpp | 修改 | 双维度平台状态与 UB override 语义 | | autofuse/inc/common/platform_context.h | 修改 | 新增目标 setter/getter 声明 | | autofuse/att/gen_model_info/api_perf_register/soc_perf_config.h | 新增 | SoC 目标、配置与解析接口 | | autofuse/att/gen_model_info/api_perf_register/soc_perf_config.cpp | 新增 | 校验、合成、缓存加固与稀疏函数解析 | | autofuse/att/gen_model_info/api_perf_register/utils/api_perf_utils.cpp | 修改 | 旧入口统一读取显式目标 | | autofuse/att/gen_model_info/api_perf_register/ascendc_api_perf.cpp | 修改 | AscendC 运行期覆盖包装 | | autofuse/att/gen_model_info/gen_model_info.cpp | 修改 | 建模入口预校验 | | autofuse/att/gen_model_info/expr_gen/pipe_perf_expr.cpp | 修改 | V35 公式失败返回 | | autofuse/codegen/codegen.cpp | 修改 | 公开 codegen 入口预校验 | | autofuse/compiler/py_module/pyautofuse.cpp | 修改 | runtime_error 转 Python 异常 | | autofuse/compiler/python/asc_codegen_compile.py | 修改 | Python 同源目标输入 | | autofuse/tests/common/att/soc_perf_test_config.h | 新增 | 只读测试 SoC 配置 | | autofuse/tests/ut/att/testcase/gen_model_info/api_perf_register/test_soc_perf_config.cpp | 新增 | 核心配置与覆盖 UT | | autofuse/tests/ut/python/test_asc_codegen_compile_soc_target.py | 新增 | 目标输入 pytest | | autofuse/tests/v35/st | 修改 | 180 个 V35 ST 夹具统一安装测试目标 | See merge request: cann/graph-autofusion!2490 | 5 天前 | |
【PR】: fix: 调整 tensor layout 工具归属和搬运模式 Co-authored-by: qq_40517592<panhailin@huawei.com> # message auto-generated for no-merge-commit merge: !1932 merge develop_0902 into develop 【PR】: fix: 调整 tensor layout 工具归属和搬运模式 Created-by: qq_40517592 Commit-by: qq_40517592 Merged-by: cann-robot Description: # Pull Request ## 描述 当前codegen和schedule对数据搬运 padding mode方式判断不一致，需要进行归一；调整 tensor layout 工具（TensorLayoutUtils）的归属位置，并重构搬运（DMA）时 padding 模式的判定逻辑：GetPaddingMode 不再依赖 tpipe 与 DataCopyParams，而是通过 TensorLayoutUtils::AnalyzeLoadDiscontinuity 分析 UB tensor 的布局属性（axis、axis_size、axis_strides、vectorized_axis）决定使用 Compact 还是 Normal 模式，同时新增对应单元测试并更新既有 codegen 测试期望 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 修复后 执行用例tc_af_tf_autofuse_pointwise_696_Cast_RealDiv_SelectV2_1170成功，精度和性能问题满足用例要求 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 变更摘要 本 PR 主要调整 tensor layout 工具（TensorLayoutUtils）的归属位置，并重构搬运（DMA）时 padding 模式的判定逻辑：GetPaddingMode 不再依赖 tpipe 与 DataCopyParams，而是通过 TensorLayoutUtils::AnalyzeLoadDiscontinuity 分析 UB tensor 的布局属性（axis、axis_size、axis_strides、vectorized_axis）决定使用 Compact 还是 Normal 模式，同时新增对应单元测试并更新既有 codegen 测试期望。 主要改动 工具归属调整: 将 tensor_layout_utils.cpp/.h 迁移至 autofuse/common/ 目录，并在 .cpp 中移除对 schedule_utils.h 的依赖。 重写 GetPaddingMode 判定逻辑: 函数签名由 GetPaddingMode(const TPipe &tpipe, const Tensor &ub_tensor, const DataCopyParams &data_copy_param) 简化为 GetPaddingMode(const Tensor &ub_tensor)，改为调用 TensorLayoutUtils::AnalyzeLoadDiscontinuity 分析 UB tensor 布局：分析成功且无多重不连续（has_multiple_discontinuities 为假）时返回 kCompactPddingMode，否则返回 kNormalPddingMode；头文件声明及 CreateEnhanceDmaCall、BuildDataCopyApiParamInNormal 两处调用点同步更新。 新增单元测试: 新增 autofuse/tests/ut/common/test_tensor_layout_utils.cpp，覆盖连续布局、单一/多重不连续、尾轴不连续、广播轴忽略，以及 vectorized_axis 缺失、布局属性长度不足返回失败等场景。 更新 codegen 测试期望: 调整 test_codegen_load_reg_api_call.cpp 与 test_codegen_store_reg_api_call.cpp 中 DataCopyPadExtend 的 PaddingMode 期望值（部分用例由 Normal 改为 Compact，部分反之），以匹配新的 padding 模式选择逻辑。 See merge request: cann/graph-autofusion!1932 | 1 个月前 | |
style: 统一 Autofuse 代码格式 Co-authored-by: Ling-DT<lingxing@huawei.com> # message auto-generated for no-merge-commit merge: !921 merge style/clang-format-autofuse-20260611 into develop style: 统一 Autofuse 代码格式 Created-by: ling-DT Commit-by: Ling-DT Merged-by: cann-robot Description: # Pull Request ## 描述 基于 cann/graph-autofusion:develop 最新提交 46a23b0，使用仓库根目录 .clang-format 对 autofuse/ 目录内受版本管理的 C/C++/AscendC 源文件执行统一格式化。 本 PR 仅包含 autofuse/ 目录格式化变更；super_kernel/ 目录格式化变更按要求暂留本地，未提交到本 PR。 格式化工具：clang-format 18.1.8，参数：--style=file。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无。 ## 如何测试 描述测试此变更的步骤和前提条件： 1. /tmp/opencode/clang-format-18-venv/bin/clang-format -i --style=file <autofuse C/C++/AscendC files> 2. git diff --cached --check 3. git diff --name-only HEAD~1..HEAD | cut -d/ -f1 | sort | uniq -c 确认 PR 提交仅包含 autofuse/。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本 PR 为纯格式化变更，不涉及功能逻辑、接口、构建脚本或打包内容修改。 See merge request: cann/graph-autofusion!921 | 3 个月前 | |
fix(cv-ubfuse): host UB 约束按原始 tmp 需求计算, 修复 matmul+pow UB 越界 Co-authored-by: tianbaolin<tianbaolin@huawei.com> # message auto-generated for no-merge-commit merge: !2297 merge tbl/fix/cv_ub_out_of_boundry into develop fix(cv-ubfuse): host UB 约束按原始 tmp 需求计算, 修复 matmul+pow UB 越界 Created-by: tianbaolin Commit-by: tianbaolin Merged-by: cann-robot Description: # Pull Request ## 描述 fix(cv-ubfuse): host UB 约束按原始 tmp 需求计算, 修复 matmul+pow UB 越界 CV UBFuse 的 Pow epilogue 内联调用 Power 高精度 API, tmp 需求为 12B/元素(如 stage=15488 时需 185856B)。device 侧已按原始公式分配 (去 v1 repeat cap), 但 host tiling 求解器的 UB 约束仍使用 capped tmp(Min(size, 65312)), 两侧不一致: 求解器按 capped 值判定 UB 可行 并选出较大 stage, 而 device 实际按原始 tmp 分配, 导致 buf_cube + b0_raw + 队列超出 UB, 设备侧报 MTE2/MTE3 地址越界。 将 is_cv_ub_fusion 透传给 AscGraphUbExprBuilder, CV UBFuse 下 UB 约束对 tmp 剥离 v1 repeat cap, 与 device 分配保持一致, 求解器据此 收缩 stage(或走 common 兜底), 使原始 tmp 能落入 UB 预算。 验证: tc_af_MMBC_0287(mm+pow CV 融合)由设备越界 Failed 恢复 Pass (100%); 新增 UT 覆盖 cap 剥离行为。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： baize 环境下测试tc_af_MMBC_0287 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!2297 | 27 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 个月前 | ||
| 3 个月前 | ||
| 3 个月前 | ||
| 1 个月前 | ||
| 3 个月前 | ||
| 1 个月前 | ||
| 26 天前 | ||
| 5 天前 | ||
| 1 个月前 | ||
| 3 个月前 | ||
| 27 天前 |