master

cann-robottest: 精简 Autofuse UT 并恢复 CPU 默认编译并行度

14cbae08创建于 5 天前历史提交

文件	最后提交记录	最后更新时间
autofuse	feat: add Autofuse template selection semantic logging Co-authored-by: zhang_shengjie<804425610@qq.com> # message auto-generated for no-merge-commit merge: !2565 merge feat/autofuse-template-selection-logging into develop feat: add Autofuse template selection semantic logging Created-by: zhang_shengjie Commit-by: zhang_shengjie Merged-by: cann-robot Description: ## 描述 ### 问题 Autofuse 选择模板后，日志里原来只能看到内部模板编号或混合命名，无法直接回答“本次实际选择了哪类实现”。同一批测试里还混有 ATT 返回方案、TopN 候选和设备执行结果，缺少稳定的身份字段后，覆盖统计容易把候选当成执行结果。 本 PR 补齐模板选择的语义日志。ATT 返回方案和 TopN 候选都输出可读模板名、候选索引和原有定位身份；名称缺失或同 key 多 subcase 无法唯一定位时显式标记，不取首个匹配冒充唯一结果。设备是否执行、精度是否通过、性能结果仍由测试数据单独判断。 日志统一使用以下命名格式： text <family>/<strategy>[@<role>][#<api-feature>|...][+<transform>+...] @ 标记 role，# 标记 API feature 组，| 分隔多个 API feature，+ 分隔已完成 transform。示例： text Reduce/RCore@Phase1 Reduce/Common#AR|ReuseSrc|MultiRound IndirectLoad/SIMD@RegisterGather Concat/UB#OneAxis Transpose/Load#Fold Broadcast/NonTail+NDDMA.Broadcast+NDDMA.Cast ### 整体设计 名称在编译期从实际调度和最终 API 分支采集，在生成 ModelInfo 时规范化。生成的 tiling 代码保留名称 getter 及 key/subcase 映射；运行期按本次返回的 tiling data 查询名称。 #### 整体时序 mermaid sequenceDiagram participant S as Schedule / generator participant C as Codegen / ApiCall participant M as 公共命名 helper / ModelInfo participant T as ATT / TopN 入口生成代码 participant O as 调用私有观察上下文 participant Q as 语义查询与日志 participant B as TopN bridge participant A as 离线 topn-templates Note over S,T: 编译期 S->>S: 记录策略、组级角色及成功转换 S->>C: ScheduledResult 与各 group 图标签 C->>C: 最终 API 分支写入 semantic_feature C->>M: group 图、策略标签及 API 参数 M->>M: 合并信息并规范化一次 M->>T: 生成 GetSemanticName 与身份映射 Note over T,A: 调用生成的 host tiling 入口 alt INFO 开启且观察初始化成功 T->>O: 建立本次调用上下文及逻辑 group 槽位 loop 原求解流程中的 group 和候选 T->>T: 求解并保留 tiling data T->>O: 记录与 data 对应的 key 和 subcase 快照 end T->>Q: 查询本次返回方案或各候选的名称 alt 有匹配当前逻辑身份和 key 的快照 Q->>T: 按快照读取对应实现的规范名称 else cache/PGO 等路径没有精确快照 Q->>T: 按当前 key 查唯一映射或共同父名及状态 end alt ATT 返回方案 Q->>Q: 输出 att_return 及可确认的 summary else TopN 候选 Q-->>T: 候选携带 semantic_infos T->>T: 按原规则去重、排序和截断 T->>B: 导出 tiling、workspace、block_dim B->>Q: 三个数组 swap 成功后输出 topn_output Q-->>A: 显式读取 worker 日志并导出 CSV/Markdown end T->>O: 退出作用域并恢复外层观察上下文 else INFO 关闭或观察不可用 T->>T: 原求解流程继续，跳过新增名称查询和记录构造 end att_return 表示 ATT 返回的方案，topn_output 表示 TopN 返回数组中的候选。设备执行、精度和性能由设备测试单独确认。TopN 的 modeled 路径、measured 路径及 default 候选共用语义查询入口；缺少精确快照的路径按已有映射回退。 #### 关键类与数据关系 类图只列名称和选择归属相关成员。ModelInfo 属于编译期数据；观察、候选和日志结构由生成的 host 代码使用。 mermaid classDiagram class ScheduleTask { string semantic_name } class ScheduledResult { string semantic_name } class CodegenApiParam { string semantic_feature } class ModelInfo { string semantic_name ScheduleGroupIdent schedule_group_ident uint32_t tiling_case_id string sub_case_tag } class TilingCaseImpl { GetSemanticName() GetSubCaseTag() GetTemplateName() } class FinalTilingObservationContext { bool enabled FinalTilingSelectionSnapshot[] selections } class FinalTilingSelectionSnapshot { bool valid uint32_t graph uint32_t result uint32_t group uint32_t tiling_key int32_t case_id int32_t sub_case_id } class AutofuseTilingDataPerf { AutofuseTilingData tiling_data double best_perf FinalTilingSelectionSnapshot[] final_tiling_selections } class CandidateSolution { AutofuseTilingData tiling_data double modeled_perf bool is_default string canonical_repr TemplateSemanticInfo[] semantic_infos } class TemplateSemanticInfo { uint32_t graph uint32_t result uint32_t group uint32_t tiling_key string semantic_name string[] semantic_names string template_name string name_status } class TemplateSemanticRecord { string stage size_t output_index uint32_t group size_t semantic_index size_t semantic_name_count string semantic_name string name_status uint32_t graph uint32_t result uint32_t tiling_key string template_name } ScheduleTask ..> ScheduledResult : 传递策略名称 ScheduledResult ..> ModelInfo : 提供策略及组图标签 CodegenApiParam ..> ModelInfo : 提供最终 API 特征 ModelInfo ..> TilingCaseImpl : 生成名称 getter 与身份映射 ModelInfo ..> TemplateSemanticInfo : 生成 key 回退映射 FinalTilingObservationContext "1" *-- "0..*" FinalTilingSelectionSnapshot : 当前调用 AutofuseTilingDataPerf "1" *-- "0..*" FinalTilingSelectionSnapshot : 当前候选 FinalTilingSelectionSnapshot ..> TilingCaseImpl : 按完整身份及 key/subcase 查询 TilingCaseImpl ..> TemplateSemanticInfo : 提供实现名称 CandidateSolution "1" *-- "0..*" TemplateSemanticInfo : 返回候选的名称 TemplateSemanticInfo ..> TemplateSemanticRecord : 输出 core / fields / detail 逻辑身份包含 graph/result/group，局部 group_id 和物理 primary namespace 都不能单独标识观察对象。reuse 返回时恢复当前逻辑组的身份；委托 primary 查询时仅映射快照副本。观察状态按调用隔离，候选快照随对应的 tiling data 保存和转移。线程局部指针用于定位当前作用域，内层调用退出后恢复外层上下文。 观察快照中的 valid 表示本次是否取得有效选择；case_id 保留已有 case 身份，sub_case_id 是生成期为 sub_case_tag 建立的编号。快照保存选择定位信息，可读名称通过对应实现的 getter 查询。无效快照不能把默认的 0/0/0 当作真实 graph/result/group。 PGO 求解候选时捕获当前 case 的选择，补齐其它 group 前恢复该候选快照，完成后更新同一候选。TopN 查询按 tiling data 实际选中的 result 遍历 group，并使用生成期固定槽位查快照；缺失或无效快照只让当前组回退。缓存和 PGO 加载路径没有精确信息时，沿当前 key 查询可确认名称，不补做求解或借用历史状态。 观察初始化、捕获、复制或名称构造失败时，关闭或降级本次诊断。真实 GetTilingCore 调用保留原返回值和异常传播。候选移动时同步移动诊断数据，去重和比较规则沿用原实现。INFO 关闭时不分配新增快照槽位，也不访问新增名称 getter；入口和选择点的分支开销仍需通过 tiling 性能 gate 验证。 ### 修改方案 #### FR01 模板命名与传递 semantic_name 描述当前 group 对应实现的分类。调度阶段记录策略和职责，Codegen 补入最终 API 特征，成功改写点记录 transform。图级名称保留自身策略和组级角色，后续确认的 API 特征和转换继续合入名称。 ##### 名称组成 名称中的 / 分隔 family 与 strategy，@ 引出 role，# 引出 API feature 组，多个 feature 用 | 分隔，多个 transform 用 + 分隔。role、API feature 和 transform 均可省略。 | 组成 | 含义与记录位置 | 示例 | |---|---|---| | family | 实现家族。由实际调度策略或公共 helper 根据组图中的实现信息确定；图改写消除原算子时保留已确认的家族标签。 | Reduce、Concat、IndirectLoad | | strategy | 家族下的实现策略。由实际 generator 或可确认的 API 分支记录。 | RCore 表示 Reduce 切 R 轴的多核策略；UB 表示片上 UB 实现；GM 表示 GM 搬运实现；SIMT 表示 SIMT 实现 | | role | 当前逻辑 group 的阶段或职责，写入对应 group 的图标签或节点角色。 | Phase1、Phase2 区分 RCore 的两个阶段；Norm 表示 Norm 分组职责 | | api-feature | 最终 API 分支已经确认的实现特征。由 Codegen 在实际选择点记录。 | AR 中 A 为保留轴、R 为归约轴，R 位于内侧；RA 的 R 位于外侧；ReuseSrc/NoReuseSrc 区分源空间复用；OneAxis 表示单轴 Concat 分支；Offset32 表示 32 位 offset 分支 | | transform | 已成功完成的图或搬运转换。转换成功后写入来源标签。 | NDDMA.Cast、NDDMA.Broadcast、LoadToNDDMA | 例如，下面的组合名称表示 Reduce 的 RCore 策略、Phase1 group、AR 且不复用源空间的 API 特征，以及已完成的 NDDMA Cast 转换。这个例子说明字段组合，不作为设备执行或精度证据。 text semantic_name="Reduce/RCore@Phase1#AR|NoReuseSrc+NDDMA.Cast" family = Reduce strategy = RCore role = Phase1 api_features = AR | NoReuseSrc transforms = NDDMA.Cast 其它组合示例： text Concat/UB#OneAxis Concat 家族，UB 策略，单轴 API 分支。 IndirectLoad/SIMT@Strided#Offset32 IndirectLoad 家族，SIMT 策略，Strided 角色，32 位 offset 分支。 Reduce/RCore@Phase1 Reduce/RCore@Phase2 两个 group 保留各自的执行阶段，允许在同一融合图中输出不同名称。 Concat/Split 保留最终 GM/UB 策略及 API 分支；Reduce 保留 AR/RA、源空间复用、RCore phase 和 merge mode 等可确认特征；Broadcast、Transpose、IndirectLoad、Softmax 的特征来自最终 API 参数、寻址策略和回退结果。MultiRound 用于标记已确认的归约合并实现特征。 核数、tile、切轴数值、dtype 和单双 buffer 等参数继续保留在原 tiling 信息中。数值变化未改变实现分类时沿用已有名称。 ##### 日志字段与名称状态 | 字段 | 含义 | 示例或边界 | |---|---|---| | semantic_name | 规范化后的完整实现名称。 | 上面的 RCore Phase1 组合名称 | | semantic_schema | fields 行中名称拆分字段的协议版本；当前为 1。字段和名称不加 v2 后缀。 | semantic_schema=1 | | family、strategy、role、api_features、transforms | formatter 从规范名称拆出的字段，便于检索与统计。 | 无 role 或 transform 时相应字段为空 | | stage | 当前记录属于哪个返回位置。 | att_return 是 ATT 返回方案；topn_output 是 TopN 候选 | | output[i] | TopN 本次返回数组中的零起始位置。 | output[0] 对应数组首项，不能直接解释为设备性能排名 | | graph、result、group | 当前逻辑 AscGraph、ScheduleResult 和 group 的编号。 | 不同 graph/result 可同时存在 group=0，需要完整三元组定位 | | tiling_key | 当前组 tiling data 中用于分发和查询的 key。 | 通过原 case/subcase 映射解释，不能从名称反推 key 或选择身份 | | template | 原内部模板定位名，对应结构体中的 template_name。 | graph0_result0_g0_0；与面向阅读的 semantic_name 分开保留 | | semantic_index | 当前 group 记录中名称的零起始序号。 | 多数记录为 0，与候选位置 output[i] 分开计数 | | semantic_name_count | 当前 group 记录中携带的名称数量。 | 1 不表示整图只有一个 group，也不表示设备只执行一个 kernel | | name_status | 名称无法唯一确认或缺失时的状态；正常唯一匹配省略该字段。 | ambiguous 表示无法唯一匹配；unavailable 表示信息不可得 | Adaptive 是名称的一部分，适用于运行时分支未确定或独立 GenerateTiling 缺少最终 API 信息等已说明条件。ambiguous 和 unavailable 是状态字段，分别说明身份匹配不唯一和信息缺失。缺少适配代码不能用 Adaptive 或默认父名掩盖。 同 key 多 subcase 且缺少精确快照时，输出可确认的共同父名并标记 ambiguous。没有可用映射时输出 Unknown/unavailable。超长核心行只保留 hash/len 摘要时，离线工具保留对应候选，将名称记为 Unknown/unavailable，并继续关联后续 detail。 ##### 公共配置与传递入口 词表统一放在 autofuse/common/common_utils.h::ascgen_utils::template_semantic；枚举到名称的映射复用公共 helper。调度和 API 选择点引用公共常量，保留原选择条件。内部来源标签经 GetTemplateSemanticName() 合并，在生成 ModelInfo 时由 NormalizeTemplateSemanticName() 规范化一次。 ATT、TopN、summary 和离线工具消费规范名称。formatter 负责拆分字段、转义与限长，Python 保留原始名称做统计。这些消费端不另建 role 表或模板选择算法，也不从 Torch 算子名、测试标签、图名或生成源码推断命中实现。 #### FR02 ATT 返回日志 ATT 成功返回的每个 group 输出一条核心日志，并按需输出 fields 和 detail 行。核心行字段顺序固定： text stage -> group -> semantic_index -> semantic_name_count -> semantic_name -> name_status(仅异常) 示例： text [ATT][TEMPLATE] stage=att_return group=0 semantic_index=0 semantic_name_count=1 semantic_name="Reduce/Common#AR|ReuseSrc|MultiRound" [ATT][TEMPLATE] stage=att_return group=0 semantic_index=0 semantic_name_count=1 fields semantic_schema=1 family="Reduce" strategy="Common" role="" api_features="AR|ReuseSrc|MultiRound" transforms="" [ATT][TEMPLATE] stage=att_return group=0 semantic_index=0 semantic_name_count=1 detail graph=0 result=0 tiling_key=0 template="graph0_result0_g0_0" case/impl 不可得或名称为空时输出 semantic_name="Unknown" name_status=unavailable；同 key 多 subcase 且无法唯一定位时保留可确认的父名并输出 name_status=ambiguous。 #### FR03 TopN 候选日志 TopN 候选继续使用零起始 output[i] 索引。tiling、workspace、block_dim 三个数组 swap 成功后才打印，避免导出失败时留下半成品日志。每个候选的每个 group 输出一条核心记录，并按 See merge request: cann/graph-autofusion!2565	9 天前
super_kernel	fix(superkernel): clean validator logs and figure names	1 个月前
build.md	test: 精简 Autofuse UT 并恢复 CPU 默认编译并行度 Co-authored-by: ling-DT<lingxing@huawei.com> # message auto-generated for no-merge-commit merge: !2656 merge test/reduce-ut-oom-restore-build-parallelism into develop test: 精简 Autofuse UT 并恢复 CPU 默认编译并行度 Created-by: ling-DT Commit-by: ling-DT Merged-by: cann-robot Description: # Pull Request ## 描述 精简 Autofuse UT 中生成源码后再次调用宿主编译器的验证，减少测试执行中的编译器子进程、临时产物以及部分测试翻译单元开销；同时减少重复仿真输入并显式释放 GM 内存。完成用例调整后，恢复 build.sh 在提交 73ef3cf9 之前的 CPU 数默认并行逻辑，以 CI 结果验证取消 14 上限后的 OOM 和耗时情况。 按 P1 → P2 → P3 分层处理： 1. P1：删除 TestGenMatmulModelInfoE2E.case1；三个 Concat 用例保留图构造、tiling 生成及字段/分组断言，删除二次编译、运行和临时 main/stub 准备。 2. P2：删除 17 个以真实编译/运行生成代码为主体的 codegen 用例，删除 CompileCode / CompileAndRunCode / CompileCodegenCode 及依赖；另外四个用例保留已有的生成结果断言，仅移除二次编译断言。所检查的 P1/P2 UT 路径不再启动宿主编译器。 3. P3：v35 Compare count 模式删去 37 组接近最大长度的重复对齐参数，保留最大长度、短输入及尾块；保留所有 dtype/mode 用例定义。为两个架构的 UnaryTest helper、普通 argmax/broadcast 和 v35 Compare 补上 GmFree。 4. 恢复 THREAD_NUM=${CPU_NUM}，同步命令行帮助；显式 -j 的校验及 CPU 数上限保持原逻辑。 共删除 18 个源码级用例定义，不增加新的测试开关或全局并行上限。生产 codegen 策略、图改写行为、API/ABI 和安装布局保持不变；追加修复仅纠正已有图名/score map 更新后的日志读取（见下文）。 注意：这批候选来自静态调用链分析，并非实测 OOM 排名。原 14 上限提交记录的是 framework ST 编译期 cc1plus 被杀；精简 UT 并不能直接证明该 ST 构建问题已解决，必须观察本 PR 的完整 CI。 ## 变更类型 - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无。本次按现有 UT 内存/耗时排查结果精简测试并撤销临时构建限制。相关历史 PR：#2623（默认并行上限 14）。 ## 如何测试 1. 本地仅执行静态检查，按要求没有本地编译、链接或运行 UT 二进制： - git diff --check：通过。 - 改动涉及的 C++ 新签名执行 clang-format 检查：通过。 - 静态核对 C++ 分隔符、18 个删除用例清单、二次编译 helper 无残留、GM 释放数量及 Compare 参数数量：通过。 - bash -n build.sh：通过。 - 提取实际默认赋值及 check_param_j 函数进行隔离 shell 检查：CPU=1/8/14/16/32/128 时默认并行分别为 1/8/14/16/32/128；32 CPU 显式 -j24 得到 24、8 CPU 显式 -j16 得到 8，空值/0/负数/非数字拒绝：通过。未执行 build.sh 构建流程。 - 两个提交的增量 OAT 检查：通过。 2. 已评论 compile 并跟踪线上 CI，最新 run #3919 对提交 cf185e37 的门禁为 ci-pipeline-passed，Actions 为 COMPLETED。四架构包编译、framework UT/ST、AscendC API UT/ST、E2E 均通过，总耗时 56:47；完整结果已在 PR 评论记录。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测（仅静态检查和隔离 shell 检查；编译与运行验证交给 PR CI） - [x] 我已更新了相关的文档（build.sh 命令行帮助） - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 覆盖率取舍 本次删除的编译/执行行为测试会减少对应的运行级回归覆盖，不能把保留的字符串/生成结构断言视为等价替代。具体包括 observation 重入/分配失败、语义名称运行时解析与 reuse 映射、TopN 去重，以及 workspace 生成代码执行等；现有其他 UT/ST 继续执行，但不声称覆盖完全等价。此 PR 的目的为按要求精简默认 UT 并在线上验证恢复并行后的资源与耗时。 ### 代码检视检查结果 - [x] 编码红线：已检查 docs/guidelines/编码红线.md，本次修改限于测试及默认并行逻辑，无新增生产资源/ABI/API 变更。 - [x] 跨特性交叉影响：已按 cross_feature_check.md 检查 Autofuse UT、AscendC 仿真、SuperKernel 共用 build.sh 和构建打包入口；默认并行变更影响全局入口，显式 -j 行为不变。 - [x] 贡献规范：已读取 CONTRIBUTING.md，使用两个职责独立提交及仓库 PR 模板。 - [x] 代码格式：已按 .clang-format 检查修改内容，未格式化无关代码。 - [x] Pre-commit：已确认 .pre-commit-config.yaml 要求并运行增量 OAT；完整 pre-commit 及本轮已执行的编译/测试通过最新 CI。 ### 追加修复：测试依赖库的编译压力 同一提交重跑的 run #3917 已在 AscendC API UT 中获得明确的 g++: fatal error: Killed signal terminated program cc1plus，对应测试专用 optimize 库的 platformv2.cpp、autoschedule.cpp 等编译对象。失败发生在 pyautofuse 的依赖构建阶段，尚未执行 API UT；仅删除用例不能覆盖这一故障路径。 追加提交 6e82e2f9 将 autofuse/tests/CMakeLists.txt 中该测试库的宿主编译优化级别从 -O2 改为 -O0，降低带覆盖率构建时的优化编译开销。保留 coverage/debug 信息及所有测试，生产 aihac_codegen 的优化级别与默认 CPU 并行逻辑保持不变。已通过 git diff --check、增量 OAT；未本地编译，已推送并触发新 CI 验证。 另已确认共享缓存 action 的健康检查存在误判：Redis 返回 LOADING Redis is loading the dataset in memory 时仍打印 Redis connection OK。该服务与 action 位于共享 CI 基础设施，本 PR 不硬编码其地址或绕过缓存设置。最新完整门禁已通过，但耗时结论仍需结合 ccache 命中率判断，不声称总耗时已达到优化目标。 ### 追加修复：移动后的 node handle 日志访问 run #3918 中，framework ST 和 AscendC API UT 已通过，API 两个架构分别通过 459、447 个测试；framework UT 完成编译后在现有 TestCodegenTiling.TestMatmulElemwiseFuse 中触发 node handle 的空值断言。 根因为 FinalizeIndexedGraphs() 将 node handle 移回 score map 后，DEBUG 日志仍读取 node.key()。追加提交 cf185e37 改为读取 insert() 返回迭代器的 key，避免访问已移动的空 handle；沿用既有索引图名生成、score 选择与 semantic_name 传递，不引入新的命名分类或 reuse 规则。复用该失败用例补充 score map key 与当前 impl graph 名称一致性的断言，覆盖实际图名更新行为。 该修复通过增量 OAT、改动行 clang-format 和 git diff --check；按要求未本地编译。已在同一 PR 推送并触发 run #3919，最新提交完整门禁通过，原失败用例所在的 framework 聚合执行完成。 ### 最终观测 最新 run #3919 总耗时 56:47，framework UT/ST、AscendC API UT/ST 和 E2E 均通过，API UT 日志记录真实 make -j96。已核查五个 Autofuse 执行 job 日志，本轮未再见编译器被杀或平台中断。 总耗时仍偏长：framework UT ccache 只有 1/1627（0.06%），缓存 action 仍返回 Redis LOADING；参考 run #3894 的命中率为 98.28%。纯 ATT/test_main 执行分别由 31.08/13.10 秒变为 21.58/4.52 秒，但 API 仿真执行时间未下降（其进程并行也从 14 变为 96）。因此只确认本轮稳定性门禁通过，不能声称整体 CI 提速完成；恢复共享缓存后应在一致环境继续比较构建和仿真并行度。 ### 同一提交三轮追加验证（#3923、#3924、#3925） 以下是同一源提交 cf185e37 的最新重复验证结果，补充前述单轮通过记录；期间没有修改代码或本地编译。 | Run | 结果 | 总耗时 | |---|---|---:| | #3923 | 完整通过 | 56:51 | | #3924 | API UT 执行任务中断，其余 Autofuse 任务通过 | 56:43 | | #3925 | 完整通过，最新门禁 passed | 56:16 | 三轮实际为 **2/3 完整通过**，不能因最新 label 为绿灯就宣称已经彻底稳定。#3924 报 CP.COMP1001 / Unsupported system retry，控制台停在测试依赖编译，尚未执行 API 用例。十五份 Autofuse 执行 job 日志中没有明确的 cc1plus Killed 或 OOM kill 记录，但缺少 pod 终止原因、退出码及 OOM 事件，**这次中断既不能确认为 OOM，也不能排除资源不足/OOM，更不能直接认定是平台自身 bug**。完整关联任务、日志和逐轮对照见最新评论。 以同样精简用例但测试库仍为 -O2 的 #3917 作 UT 基准，CTest 纯聚合执行时间如下： | 聚合部分 | -O2 基准 | 三轮 -O0 均值 | 差值 | 相对变化 | |---|---:|---:|---:|---:| | optimize UT | 4.86s | 5.253s | +0.393s | +8.09% | | test_main UT | 4.38s | 4.400s | +0.020s | +0.46% | | ATT UT | 21.62s | 21.563s | -0.057s | -0.26% | | common UT | 0.07s | 0.070s | 0s | 0% | 四个 framework UT 聚合部分合计由 30.93s 变为平均 31.287s，增加约 0.357s（1.15%）。optimize UT 范围为 5.18～5.38s。optimize ST 的 -O0 均值为 2.52s，但 #3917 的 ST 构建中断，没有同版 -O2 执行基准，故不计算精确增量。 以上不是编译时间、整 job 时间或单个 gtest case 时间。跨轮次存在环境波动，最新代码还包含必要日志修复与断言，因此不是严格单变量 A/B 实验。三轮 framework UT 的 ccache 均为 0.06%，缓存 action 仍返回 Redis LOADING；约 0.36s 的纯执行差异不能解释整轮 56～57 分钟。没有把中断 API UT 的缺失执行时间按 0 秒计算，也没有将它纳入成功执行均值。 ### #3924 失败口径修正：按疑似 OOM / 进程被杀处理 按本次排障口径，**#3924 API UT 的“无正常结束日志、任务突然终止”应计为疑似 OOM / 进程被杀的失败，不作为可忽略的外部平台故障，也不能据另外两轮通过宣称 OOM 已经解决。** “平台中断”此前仅用于描述 CI 返回的 CP.COMP1001 / Unsupported system retry，不表示已排除资源不足或 OOM。整个 runner/pod 被杀时，日志代理及编译进程可能一并终止，确实可能没有机会输出 cc1plus Killed 或正常退出码。 再次核对的事实： - API UT 执行 job：1781d8bb41944ff4bb6a9311998cf16f。 - 构建控制台最后时间为 2026-10-25 20:21:29 +08:00，末尾仍是测试公共依赖的源码编译信息，涉及 codegen.cpp 等；尚未执行 API gtest。 - 平台在 20:25:05 回收 runner 后报告 CP.COMP1001 / Unsupported system retry。 - job/step API 也没有返回进程退出码或具体终止原因，只有“步骤 ut 执行失败”。 - 并行编译的日志会交错，末尾文件名不等于已确定的被杀编译单元，更不是已定位到某个 API 用例。 因此，本次三轮结果应理解为 **2 轮通过、1 轮按 OOM 场景排查的失败**。技术取证上仍缺 pod OOMKilled、退出码 137 或宿主机/cgroup OOM 事件，以区分“疑似”和“已确认”的根因证据；这一证据缺口不影响将该轮保留为未解决的 OOM 风险。 下一步的修复定位应围绕测试公共库编译阶段的内存峰值、并行进程及 runner 资源，不能仅靠继续删除 API 执行用例或排除这次失败来得出稳定结论。 ### 追加修复 2bf3a560：隔离纯 API UT 构建依赖，重新验证连续三轮 此前 #3924 按本次口径计为 OOM 失败，旧提交的连续通过记录不足以验收。本次从源提交 2bf3a560 重新计数；任何 CI 中断或进程被杀均计失败并清零，要求同一提交连续 3 轮完整通过。 定位到纯 API UT 的额外构建链：build.sh 先全量构建产品，测试入口又先构建测试版 pyautofuse，并混合构建两个广播 codegen E2E 目标，进而拉入 optimize/codegen 等库。#3924 在这一公共依赖构建阶段中断，尚未执行数值 API UT。 本次修改： 1. 仅选择 Autofuse 测试模块且没有 --pkg 时，交由测试入口构建目标依赖，去掉预先的产品全量构建；打包、非 Autofuse 和混合测试入口保持原流程，--no-autofuse 仍生效。 2. 纯 AscendC API UT 直接配置并构建两个架构的数值 API 测试，不再预先构建测试版 pyautofuse/optimize/codegen。 3. 两个广播 codegen E2E 目标及其 29 个用例归入现有 E2E ST 入口；完整 Autofuse UT -u -m all 也继续运行，未删除覆盖。下一轮检查其实际执行数量。 4. 显式保留请求的 Release/Debug 构建类型，测试配置重置 BUILD_AUTOFUSE=ON 及独立 SuperKernel 测试开关，避免依赖旧产品构建留下的 CMake 缓存。 5. 测试入口在开始和退出时输出 CPU/cgroup 内存上限、峰值和 OOM 计数，退出日志不会吞掉真实构建错误。 **没有恢复全局 14 并行上限，没有新增测试跳过开关。** THREAD_NUM=${CPU_NUM} 及显式 -j 的原校验逻辑保持不变。 本地仅运行无编译的脚本路由测试：CMake、Make、编译器和 CTest 全部为桩，24 项通过；覆盖产品/测试构建选择、--pkg/--no-autofuse、Debug 参数传递、API 与 E2E 路由及失败状态不被资源日志隐藏。Ruff、Shell 语法、git diff --check 和增量 OAT 通过，未本地编译。 当前验证从 run #3926 开始，尚未完成新提交的三连通过。将核查 API UT 无多余 codegen 编译、两个架构数值用例数以及 E2E 入口中的 29 个广播用例，并保留 -O0 执行耗时观测。 ### 追加修复 a9684d96：按容器实际 CPU 配额构建，重新计数三连通过 新资源记录给出了关键差异（来自正确 Checkout 的 #3929）： | 任务 | 宿主机暴露 CPU | cgroup CPU 配额 | cgroup 内存上限 | 修复前构建并行 | |---|---:|---:|---:|---:| | API UT | 96 | 1600000 / 100000 = 16 | 64 GiB | 96 | | framework UT | 96 | 3200000 / 100000 = 32 | 128 GiB | 96 | /proc/cpuinfo / 亲和性显示的 96 核不是容器可使用的 96 核计算预算。两类任务此前使用同样的 96 路编译，但 API UT 只有一半 CPU/内存预算，构建超配是必须修正的实际问题。 提交 a9684d96： - 默认 CPU 数改为 nproc 亲和性和 cgroup CPU quota 的较小值，兼容 cgroup v2 和常见 v1 挂载；分数配额向上取整，至少一个工作进程，忽略 OpenMP 运行时线程设置但不修改调用方的设置。 - 保持 THREAD_NUM=${CPU_NUM}，没有恢复固定 14 上限。显式 -j 仍按既有规则校验并受 CPU 数上限约束，只是该上限现在取进程实际可用 CPU，而不是误用宿主机核数。 - 修复隔离 API UT 入口对空工作区的初始化：自行创建并进入构建目录，CMake 配置失败立即返回，避免落到父目录或继续构建旧目标。 - 路由测试从空目录开始，并检查工作目录和失败传播，覆盖配额 16/32、亲和性约束、无限/分数配额、边界数值及 OpenMP 设置保留等情形。 验证过程如实保留：#3926 实际 Checkout 仍是旧 cf185e37 的合并预览，已作废，不计入新修复验收；#3929 正确运行 2bf3a560，暴露 API 初始化遗漏，已修复。该轮其他 Autofuse 任务通过，E2E 入口实际执行并通过迁移的 **29 个广播用例**。 本地仍未进行编译。38 项构建工具全桩的脚本测试通过，Ruff、Shell 语法、git diff --check 和增量 OAT 通过。 已等待并核对远端合并预览包含 a9684d96 后触发 #3931。有效连续计数重新从 0/3 开始；后续既检查完整门禁，也核对实际 Checkout、数值 API/广播 E2E 数量和资源/OOM 计数。任何中断、进程被杀或其他 CI 失败均清零，同一提交连续三轮完整通过后再验收。 ### 最终验收：同一提交连续三轮完整 CI 通过（3/3） 源提交：0ee7e23932d03f5f80b5a00f140dff6b74d09d99。 三轮均等上一轮顶层完全结束后再评论 compile，期间无代码变更。每轮五项 Autofuse 执行任务的实际 Checkout 共 15 份均为 28f51962e7b42ea19e2305f4f8a52e09a839556d，已通过 Git 祖先校验确认包含上述源提交；没有采用 v8 接口重复显示的 SHA 判断版本。 | 轮次 | 流水线 | 顶层结果 | 全流程耗时 | 连续通过 | |---|---|---|---|---| | 1 | [#3934](https://gitcode.com/cann/graph-autofusion/actions/runs/18b2154f75ae4764875d519c2485e4c3) | COMPLETED，gate=passed | 3112s / 51m52s | 1/3 | | 2 | [#3935](https://gitcode.com/cann/graph-autofusion/actions/runs/2d984bb52dd04c9d9447f510acc285dc) | COMPLETED，gate=passed | 3116s / 51m56s | 2/3 | | 3 | [#3936](https://gitcode.com/cann/graph-autofusion/actions/runs/6597bc2d554a4bfc825f707c457f8b83) | COMPLETED，gate=passed | 3126s / 52m06s | **3/3** | 每轮 workflow 的四项 X86/ARM 编译、precommit、已启用 SuperKernel Python 测试、五项 Autofuse 测试及报告阶段全部通过。SuperKernel C++ 测试及 PreSmoke 保持 workflow 的 IGNORED 状态，不计为已执行覆盖。 #### OOM 与任务完整性 - 三轮五项 Autofuse 执行日志均有资源 start/exit 记录，测试正常结束；未发现执行中断、进程被杀、Killed signal、CP.COMP、segfault 或非零退出记录。 - framework UT、framework ST、API UT/ST 的 cgroup v2 memory.events：三轮 oom 和 oom_kill 起止增量全部为 0。 - E2E 三轮实际使用 cgroup v1：memory.oom_control 的 oom_kill 起止增量全部为 0；不将 v1 未提供的 v2 oom 计数虚构为测量值。 - 继续采用约定：执行中断或进程被杀即按 OOM 验收失败处理，不以缺少 OOMKilled 记录豁免；任何失败清零。本次最终三轮没有此类记录。 #### 构建路由与覆盖证据 | 检查项 | 三轮结果 | |---|---| | API UT 并行度 | build_jobs=16 / make -j16，匹配 16 CPU、64 GiB 容器配额 | | framework UT 并行度 | build_jobs=32，匹配 32 CPU、128 GiB 容器配额 | | framework ST、 See merge request: cann/graph-autofusion!2656	5 天前
opencode-skill-management.md	【fix】: AF资料中补充英文版opencode-skill-management描述 Co-authored-by: nikson<nisong1@huawei.com> # message auto-generated for no-merge-commit merge: !2284 merge ns-dev into develop 【fix】: AF资料中补充英文版opencode-skill-management描述 Created-by: tourse Commit-by: nikson Merged-by: cann-robot Description: # Pull Request ## 描述 AF资料中补充英文版opencode-skill-management描述 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 1. 验证README_en.md中相应Skills Management Guide超链接能正确跳转到新文件中 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!2284	1 个月前
precommit_guide.md	docs: 修复文档中文标点、失效链接与公网地址声明表(#318) Co-authored-by: hamburgerbobo<gaoyubo4@huawei.com> # message auto-generated for no-merge-commit merge: !2136 merge docs/fix-md-problems into develop docs: 修复文档中文标点、失效链接与公网地址声明表(#318) Created-by: hamburgerbobo Commit-by: hamburgerbobo Merged-by: cann-robot Description: # Pull Request ## 描述 按文档批量审核结果（见关联 Issue）修复 22 个文件，均为纯文档与文档配套脚本修改，不改变任何代码语义（SuperKernel 相关文件按要求不在本 PR 处理，见文末说明）： 1. 中文语境英文标点改为中文标点：AGENTS.md（6 处）、SECURITY.md（3 处）、docs/zh/precommit_guide.md（46 处）、docs/zh/autofuse/design/features/reduce.md（12 处）、slice_split.md（9 处）、docs/zh/build.md（2 处）、profiler ReadMe（3 处）、示例 README（1 处）。 2. 失效链接修复：architecture.md 已由 design/ 迁移至 introduction/（commit 035eed5d、3f0fb3e1），修复 README.md、README_en.md 及 EN codegen.md、schedule.md 共 4 处遗留旧链接。 3. docs/zh/build.md 示例路径 python3.7.5 改为 python3.x 占位写法，消除与 Python3>=3.8.0 的矛盾。 4. scripts/check_env.sh：新增 REQUIRED_GCC_MIN=7.3.0 与 GCC 版本校验（低版本报 ERROR），同步修正 build.md 已列出 GCC 依赖后的过时注释。 5. autofuse/README.md 第 49 行 3 处 Pytorch 统一为 PyTorch。 6. SECURITY.md/SECURITY_en.md 公网地址声明表：makeself 行的文件名更正为实际包含该 URL 的 docs/zh/build.md、docs/en/build.md；新增 cmake/fetch_cann_cmake.cmake 的 https://gitcode.com/cann/cmake.git 声明行。 7. README.md/README_en.md 目录树补充 docs/ 子目录（env_install/、figures/、guidelines/）与 scripts/reject_forbidden_paths.sh。 ## 变更类型 - [x] 📝 文档内容更新 ## 关联的Issue Closes #318 ## 如何测试 1. bash scripts/check_env.sh：确认 GCC 检查输出 [PASS] GCC x.x.x (>= 7.3.0) 2. pre-commit run --files <变更文件>：OAT Compliance Check 已本地通过 3. 核对 README 目录树与 docs/、scripts/ 实际内容一致；4 处链接目标文件均存在 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（docs:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 分支基于 upstream/develop（34580490）创建，行号已按最新基线核对。 - check_env.sh 为唯一脚本改动：仅 GCC 检查段新增版本比较，本地 bash -n 与实际运行均通过。 - 合入后建议执行 pre-commit run oat-check --all-files 复核声明表。 ## 双语配对同步说明（CI codecheck 要求） CI 的 md 双语配对检查要求：修改任一语言版本时，其配对文件（zh↔en 或 README↔README_en）须在同一 PR 中同步修改。本次按此要求补充以下同步修改： 1. autofuse/README_en.md：修正 TensorFlow 用例链接误指向中文版 README.md 的问题（改为 README_en.md）。 2. docs/en/build.md：与 docs/zh/build.md 同步，将 python3.7.5 示例路径改为 python3.x 占位写法。 3. docs/{zh,en}/autofuse/design/features/reduce.md、slice_split.md 与 docs/zh/.../codegen.md、schedule.md：统一补充"相关链接/Related Links"尾注，返回 AutoFuse 架构介绍（对齐 EN codegen/schedule 既有约定）。 4. docs/{zh,en}/precommit_guide.md：补充语言切换链接（对齐 autofuse/README 既有约定）。 5. profiler 说明文档 ReadMe.md 更名为 README.md（对齐仓库其余测试目录命名），标题规范为 Markdown 标题，README_en.md 补文件末尾换行。 ## SuperKernel 相关文件说明 按要求，以下 SuperKernel 相关修复不在本 PR 处理，待后续单独提交： - super_kernel/README.md 的 U+200B 零宽空格清理 - docs/{zh,en}/super_kernel/figures/ 下含空格文件名重命名（ICachePreload_ optimization.*、super kernel_diagram.excalidraw）及其引用更新 - docs/{zh,en}/super_kernel/super_kernel_migration_design.md 中文语境括号修正与语言切换链接 - super_kernel/examples/super_kernel_runtime_ascendc_only/README{,_en}.md 标点修正与语言切换链接 See merge request: cann/graph-autofusion!2136	1 个月前
project_prompts.md	docs: 文档国际化改造，支持中英文双语	5 个月前
quick_install.md	【PR】: 完善脚本，增强健壮性。修复了4处文档中的路径错误 Co-authored-by: @gcw_Xt6hqG9y<1634807286@qq.com> # message auto-generated for no-merge-commit merge: !1528 merge shell_fix into develop 【PR】: 完善脚本，增强健壮性。修复了4处文档中的路径错误 Created-by: gcw_Xt6hqG9y Commit-by: @gcw_Xt6hqG9y Merged-by: cann-robot Description: # Pull Request ## 描述 完善脚本，增强健壮性。修复了4处文档中的路径错误。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.在CANNLab平台上执行没问题 2. ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!1528	3 个月前
skill-reuse-guide.md	[feat] add superkernel auto tune skill	1 个月前