CANN算子测试赛Add报告

【免费下载链接】cann-competitions本仓库用于 CANN 开源社区各类竞赛、开源课题、社区任务等课题发布、开发者作品提交和展示。项目地址: https://gitcode.com/cann/cann-competitions

===== 元信息（请如实填写，此区块将由组委会脚本自动解析，请保持字段名不变）=====

team_name: "蕉不绿队"

team_members:

• "成员1：姚杰涛-广州大学"
• "成员2：张欢-广州大学"
• "成员3：陈贝宁-广州大学"

operator_name: "Add"

operator_library: "cann-ops-math"

report_date: "2026-04-25"

Add 算子最终测试结果报告

本报告基于当前版本test_aclnn_add.cpp的执行结果，以及 4 个评分文件对应的.gcov产物整理形成。与上一版报告相比，这一版结论以本轮真实覆盖率为准，重点说明当前测试已经打到的主路径、仍未进入的分支，以及导致综合覆盖率下降的核心原因。

一、结果概览

本次实际统计的 4 个评分文件及覆盖率结果如下：

按文件行数和分支数加权后，本轮综合结果约为：

• 综合行覆盖率：63.28%
• 综合分支覆盖率：54.46%
• 综合“至少命中一次”分支比例：30.86%
• 综合调用覆盖率：60.78%

从结果可以直接看出：

1. add.cpp、aclnn_add.cpp、aclnn_add_v3.cpp三个op_api文件的覆盖率已经明显提升，主流程、异常输入和部分边界路径已经进入。
2. 当前综合覆盖率被add_tiling_arch35.cpp的0.00%明显拉低。
3. 因此，这一轮测试的主问题已经不再是op_api主路径完全没打到，而是host tiling路径完全没有进入。

二、结合.gcov的逐文件分析

1.math/add/op_api/add.cpp

该文件当前表现最好，行覆盖率达到89.09%，分支覆盖率达到74.90%。结合.gcov可见，以下关键路径已经被覆盖：

• Add的 broadcast 成功与失败路径均已进入。
• AiCore与AiCpu两条调度路径均被打到。
• mixed dtype 分支已经命中，float16 + float、float + float16、bf16 + float等输出转为float的逻辑被实际执行。
• l0op::Add的非法 broadcast 失败路径已进入。
• AddAiCore、AddAiCpu两个底层调度函数都已被执行。

当前主要剩余缺口有：

• DAV_3102对应的ASCEND610LITE_AICORE_DTYPE_SUPPORT_LIST分支未命中。
• IsAddSupportNonContiguous只有IsRegBase()==false的返回路径，未体现真正的非连续输入支持分支。
• AddInplace虽然进入了失败分支校验，但.gcov显示成功调度到AddAiCore或AddAiCpu的路径并未命中，说明当前更多是在测它的失败保护，而不是成功执行。

这说明add.cpp这一层的核心调度逻辑已经覆盖得比较充分，但架构特定分支与L0 AddInplace成功路径仍有缺口。

2.math/add/op_api/aclnn_add.cpp

该文件当前行覆盖率71.53%，分支覆盖率54.52%，已经从“只打到少量主路径”提升到了“主路径 + 部分异常路径都进入”的状态。结合.gcov，当前已经明确命中的内容包括：

• CheckNotNull的多种空指针失败分支。
• CheckPromoteType中alpha可转换 / 不可转换、输出类型可转换 / 不可转换等路径。
• CheckInplace中 broadcast 推导、shape 检查成功与失败路径。
• aclnnAddGetWorkspaceSize主流程。
• aclnnAddsGetWorkspaceSize、aclnnInplaceAddGetWorkspaceSize、aclnnInplaceAddsGetWorkspaceSize等接口入口。
• alpha==1直走Add、Axpy路径、Mul+Addfallback 路径都已经命中。
• bool、mixed dtype、空 tensor、非法 shape、非法 alpha 等测试都对该文件分支覆盖有直接贡献。

.gcov同时也显示出当前还没有覆盖到的典型区域：

• GetScalarDefaultDtype
• InnerTypeToComplexType
• CombineCategoriesWithComplex
• GetCastedFloat

这些函数全部是called 0，说明当前复杂数相关、部分特殊 scalar 推导路径没有真正进入。

另外，.gcov还显示：

• aclnnInplaceAdd运行接口本身未被执行。
• aclnnInplaceAdds运行接口本身未被执行。

这说明当前测试更多打到了GetWorkspaceSize和参数校验入口，但对应的最终执行封装函数并没有留下运行覆盖。也就是说，Inplace系列“前半段”覆盖得不错，“执行落地”这一小段还需要补。

3.math/add/op_api/aclnn_add_v3.cpp

该文件当前行覆盖率90.79%，分支覆盖率64.55%，是本轮覆盖最好的文件之一。结合.gcov可确认：

• CheckNotNull、CheckShape、CheckParams的主要真/假分支已被覆盖。
• PromoteTypeScalar的多条推导路径被实际命中。
• alpha==1直走Add、Axpy路径、Mul+Add路径都已执行。
• 空 tensor 快速返回路径已命中。
• promote -> out不可转换、shape 不匹配、max dim exceeded、不支持 dtype 等失败路径已进入。
• AddV3的标量 + tensor 主语义已经测透到了较深位置。

当前明显未覆盖的点主要有：

• aclnnInplaceAddV3运行接口called 0。
• promoteType == DT_BOOL这类很窄的分支没有打到。
• promoteType == DT_UNDEFINED的失败路径没有打到。

因此，aclnn_add_v3.cpp当前的状态可以判断为：主功能、主要异常输入、主要类型约束都已经覆盖到位，剩余缺口主要集中在非常窄的特殊类型分支和InplaceAddV3的最终执行封装。

4.math/add/op_host/arch35/add_tiling_arch35.cpp

这是本轮最关键的问题文件。当前结果是：

• 行覆盖率：0.00%
• 分支覆盖率：0.00%
• 调用覆盖率：0.00%

从.gcov可见，该文件中所有关键函数均为called 0，包括：

• AddTiling::IsMixedDtype
• AddTiling::CheckDtype
• AddTiling::DoOpTiling
• TilingForAdd
• TilingPrepareForAdd

这说明本轮执行过程中，host tiling路径完全没有进入。

基于.gcov可以做出一个明确判断：当前测试集虽然已经把op_api层覆盖得比较充分，但没有驱动到arch35对应的 tiling 编译/解析/模板分发路径。因此上一版报告里关于add_tiling_arch35.cpp的高覆盖结论，在本轮结果下已经不再成立，最终报告必须以本轮0.00%为准。

三、本轮测试内容能说明什么

从test_aclnn_add.cpp当前用例内容看，这一轮测试已经覆盖了以下几类核心场景：

1. 常规正确性路径

• float32 broadcast + alpha!=1
• int32 + alpha=2
• float16 + float32
• float32 + float16
• double + alpha!=1触发Mul+Add路径
• alpha=0的高维 broadcast
• bool特殊分支
• int8、uint8、int64边界值
• NaN / Inf特殊浮点值

这些用例保证了 Add 的主数值语义已经不是空白覆盖。

2. API 变体路径

• Adds
• InplaceAdd
• InplaceAdds
• AddV3
• InplaceAddV3

并且对其中相当一部分接口补了：

• alpha==1
• 负 alpha
• mixed dtype
• out dtype cast
• 空 tensor
• 非 ND format

因此当前op_api三个文件的覆盖提升是有真实用例支撑的，不是靠少量“撞到主函数”得来的。

3. 失败路径与边界路径

当前测试还显式包含了大量失败场景，例如：

• nullptr 输入
• alpha为空
• 非法 broadcast
• out shape 不匹配
• max dim exceeded
• alpha不可转换
• promote -> out不可转换
• AddV3不支持 dtype
• L0 Add/L0 AddInplace非法输入

这也是为什么当前aclnn_add.cpp和aclnn_add_v3.cpp的分支覆盖率能比上一版明显提高。

五、结论

Add 测试的真实状态可以概括为：

• op_api层已经从“基础覆盖”进入到“主路径 + 异常路径都较充分”的阶段。
• add.cpp、aclnn_add.cpp、aclnn_add_v3.cpp的结果说明当前测试方案对 eager / op_api 层是有效的。
• 最大短板已经不是普通 Add/Adds/AddV3 的数值正确性，而是host tiling路径完全未进入。

【免费下载链接】cann-competitions本仓库用于 CANN 开源社区各类竞赛、开源课题、社区任务等课题发布、开发者作品提交和展示。项目地址: https://gitcode.com/cann/cann-competitions