| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 | 4 天前 | |
docs: 补充Autofuse样例运行依赖排查说明 Co-authored-by: yixiqin<yixiqin@huawei.com> # message auto-generated for no-merge-commit merge: !2548 merge eco1015 into develop docs: 补充Autofuse样例运行依赖排查说明 Created-by: yixiqin Commit-by: yixiqin Merged-by: cann-robot Description: # Pull Request ## 描述 在 autofuse/README.md、autofuse/README_en.md 与 docs/env_install/pytorch/env_pytorch.md 中补充 Autofuse 样例运行依赖的排查说明。 新手使用 torch_npu Daily 环境运行 python3 af_add_ge.py 等官方用例时，首次触发融合算子代码生成会报错： RuntimeError: Failed to build ascend kernel. trigger bug by following command: '.../asc_tilling.py' 该报错把真实失败原因包装成"触发 bug 的命令"，未暴露缺失依赖线索。真实根因（如 ModuleNotFoundError: No module named 'decorator'）需手动执行报错中的 .py 文件才能看到，逐层补装后还会接连缺失 scipy、attr 等包。这些包均收录在 super_kernel/requirements-dev.txt 中，但该清单此前只用于构建环境，样例环境依赖文档未声明。 本次变更在两处文档新增"样例运行依赖"说明：提醒开发者在遇到上述报错时，手动执行报错中的 py 文件、按提示安装缺失依赖，或一次性执行 pip3 install -r super_kernel/requirements-dev.txt。 ## 变更类型 - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 无 ## 如何测试 文档变更，无需功能测试。 1. 预览 autofuse/README.md、autofuse/README_en.md 与 docs/env_install/pytorch/env_pytorch.md 渲染效果。 2. 确认新增小节的命令与相对路径正确（super_kernel/requirements-dev.txt 位于仓库根目录）。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 无 See merge request: cann/graph-autofusion!2548 | 15 天前 | |
【PR】: 更新安装方式 Co-authored-by: sophia1213<sophie.chen@huawei.com> # message auto-generated for no-merge-commit merge: !1244 merge develop into develop 【PR】: 更新安装方式 Created-by: sophia1213 Commit-by: sophia1213 Merged-by: cann-robot Description: # Pull Request ## 描述 更新CANN安装方式中的CANNLAB安装方式，包括更新图片以及安装步骤说明等 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 无 ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/graph-autofusion!1244 | 3 个月前 | |
docs: 补充项目规范指导(#95) Co-authored-by: Jett_Woo<wujinteng1@huawei.com> # message auto-generated for no-merge-commit merge: !732 merge feature/project-spec into develop docs: 补充项目规范指导(#95) Created-by: Jett_Woo Commit-by: Jett_Woo Merged-by: cann-robot Description: # Pull Request ## 描述 补充 Graph-autofusion 项目级 agent 指导和规范文档，并增强 af-code-reviewer skill 的代码检视流程。 主要变更： - 新增 AGENTS.md，说明项目结构、构建测试入口、设计文档要求、GitCode 流程和 agent 工作规范。 - 新增 docs/guidelines/cross_feature_check.md，提供 SuperKernel、Autofuse、构建交付、测试和性能场景的交叉影响检查表。 - 新增 docs/guidelines/design_document_template.md，提供 Graph-autofusion 设计文档模板。 - 新增 docs/guidelines/编码红线.md，补充安全、资源、ABI/API、图改写、runtime 生命周期和构建交付红线。 - 优化 .claude/skills/af-code-reviewer，要求代码检视前读取规范并输出固定格式检查结果。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue Closes #95 Issue 地址：https://gitcode.com/cann/graph-autofusion/issues/95 ## 如何测试 描述测试此变更的步骤和前提条件： 1. 执行规范文件存在性和关键内容检查： test -f AGENTS.md && test -f docs/guidelines/design_document_template.md && test -f docs/guidelines/cross_feature_check.md && test -f docs/guidelines/编码红线.md && grep -q "af-code-reviewer" AGENTS.md && grep -q "af-build-runner" AGENTS.md && grep -q "af-test-developer" AGENTS.md && grep -q "编码红线" .claude/skills/af-code-reviewer/SKILL.md && grep -q "跨特性交叉影响" .claude/skills/af-code-reviewer/SKILL.md && grep -q "代码检视检查结果" .claude/skills/af-code-reviewer/SKILL.md && grep -q "SuperKernel" docs/guidelines/cross_feature_check.md && grep -q "Autofuse" docs/guidelines/cross_feature_check.md 2. 检查 PR diff 范围： git diff --stat upstream/develop...HEAD ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本次仅补充项目规范、agent 指导和 skill 文档，不涉及源码、构建脚本或测试代码变更。 See merge request: cann/graph-autofusion!732 | 4 个月前 | |
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 | 4 天前 |