Thanks for sending an issue! Please fill in the following template to help quickly solve your problem.

Describe the current behavior / 问题描述 (Mandatory / 必填)

1. 现象：racecheck 报 28 条 GM WAW（Write-After-Write）

算子 conv3d_backprop_filter_v2 在 Ascend950 上使用 MindStudio Sanitizer（mssanitizer）做竞争检测（racecheck）时，检测出 28 条 Potential WAW hazard detected at GM，事件全部集中在 ClearWorkspace（清零 GM workspace）的写操作，例如：

ERROR: Potential WAW hazard detected at GM in Conv3DBackpropFilterV2_..._execution_0:
    PIPE_MTE3 Write at WAW()+0x1201a2200000 in block 0 (aiv) ... pc 0x47b78 (serialNo:81)
    #0 conv3d_backprop_filter_v2.h:316 (ClearWorkspace)
    #1 conv3d_dw_v2_basic_block.h:236 (CalcIterate)
    ...
    PIPE_MTE3 Write at WAW()+0x1201a2200000 in block 1 (aiv) ... pc 0x47b78 (serialNo:204)

地址规律非常强：block(2k) 与 block(2k+1) 写同一个 GM 地址，相邻对的地址间隔 0x40000（256KB），正好等于算子的 CUBE_WORKSPACE = TOTAL_L0C_SIZE。共 28 对，覆盖 block 0–55。

2. 线索：同一 GM 地址被"一对 AIV"写

工具日志（mssanitizer_*.log）显示：

Receive kernel summary. ... blockDim:28, kernelType:3
aic-0..aic-27  = 28 个 cube
aiv-0..aiv-55  = 56 个 vector   // 每 cube 配 2 个 aiv

• kernel 实际只启动 28 个物理核（blockDim=28）；
• 但 race 检测按 aiv 逻辑核 粒度（56 个）做跨核检测；
• 每个物理核含 1 个 AIC + 2 个 AIV（aic-k → aiv-2k/aiv-2k+1）。

对应的事件流（均为 ClearWorkspace 的 GM 清零写，同一指令 pc=0x47b78）：

MOV_ALIGN_V2, 81,  aiv-0, dst: GM 0x1201a2200000   // aiv-0 清零
MOV_ALIGN_V2, 204, aiv-1, dst: GM 0x1201a2200000   // aiv-1 清同一地址

即 同一物理核的两个 AIV（aiv-0/aiv-1）都在执行 ClearWorkspace，向同一块 GM workspace 清零，且各自写前没有等待对方的写完成信号（aiv-1 写前等待的 flagid:12/9 与 aiv-0 写后发出的 flagid:2 不配对）。

3. 分析：Ascend950 双 AIV 可并行、需要 AIV 间同步

在 Ascend950（__NPU_ARCH__ == 3510）上，同一物理核的两个 vector 单元（AIV）是可独立并行的执行流，它们之间确实可能存在竞争，也存在 AIV 间的同步指令。因此 racecheck 将 aiv-0/aiv-1 作为独立执行流检测跨核写写冲突是合理的。

算子代码也明确为 3510 双 AIV 做了适配（见 conv_bp_sub_func_deterministic_calculate.h，均在 #if __NPU_ARCH__ == 3510 下）：

subCoreInx_ = (isOddCore << 1) + GetSubBlockIdx();   // 双 AIV → 不同 subCoreInx
... addrOffset[this->ctx.subCoreInx_] ...            // 归约读写按 sub-core 分独立子区域
... + GetSubBlockIdx() * QUARTER_CUBE_WORKSPACE      // GM 输出按 sub-block 分区域

说明算子知道双 AIV 会并行、需要给它们分独立子区域。但 ClearWorkspace（清零路径）漏了这条处理。

4. 根因：ClearWorkspace 无条件被双 AIV 执行，清同一块 GM workspace 且无 AIV 间同步

conv3d_dw_v2_basic_block.h 的 CalcIterate AIV 段：

if ASCEND_IS_AIV {
    this->ClearWorkspace(this->workspaceGm_[this->offsetCubeWorkSpaceC_]);  // ❌ 无条件，双 AIV 都执行
    VecNotifyCube();
    this->dw_.Iterate();
    VecWaitCube();
    if (isCurIter) {
        this->dw_.DeterministicReduceKInUb(this->yGm_[this->offsetC_], this->workspaceGm_);
    }
    ...
}

• ClearWorkspace 清的目标是 workspaceGm_[offsetCubeWorkSpaceC_]，offsetCubeWorkSpaceC_（conv3d_dw_v2_basic_block.h:125）只按 block/core 维度计算，不含 GetSubBlockIdx()，即清的是整块 block 级 GM workspace（CUBE_WORKSPACE 粒度）；
• 该段没有 GetSubBlockIdx() 条件，双 AIV 都会执行清零写同一块 GM workspace；
• ClearWorkspace 内部只有核内 pipe 事件同步（MTE3_V/V_MTE3/MTE3_MTE2），其后经共享 cube 的 VecNotifyCube/VecWaitCube 只同步 AIV↔AIC，双 AIV 之间没有直接同步指令；
• 反观算子其它访问（归约/输出）都用 GetSubBlockIdx()*QUARTER_CUBE_WORKSPACE 或 addrOffset[subCoreInx] 给双 AIV 分配了独立子区域——唯独清零路径没有。

因此：同一物理核的两个 AIV 无同步地写同一块 GM workspace，构成真实的 WAW，racecheck 检出合理。

注：ClearWorkspace 是"清 0"，若两次清零恰好都发生在各自计算写 workspace 之前，结果可能暂不受影响（example 结果正确），但存在"一个 AIV 的清零晚于另一个 AIV 的计算写入"导致结果被清掉的理论风险，属于隐患，且 racecheck 报竞争符合预期。

5. 涉及代码位置（ops-nn 仓）

Environment / 环境信息 (Mandatory / 必填)

环境信息

Steps to reproduce the issue / 重现步骤 (Mandatory / 必填)

重现步骤

1. 编译算子并开启 mssanitizer 插桩：

   cd ops-nn
   bash build.sh --pkg --soc=ascend950 --ops=conv3d_backprop_filter_v2 -j96 --mssanitizer
   ./build_out/cann-ops-nn-custom_linux-x86_64.run   # 部署
   

2. 编译并运行 eager example（生成检测载体二进制）：

   bash build.sh --run_example conv3d_backprop_filter_v2 eager --soc=ascend950
   

3. 运行竞争检测：

   cd ops-nn/build
   mssanitizer -t racecheck --log-level=error -- ./test_aclnn_conv3d_backprop_filter_v2
   

4. 观察输出：出现 28 条 ERROR: Potential WAW hazard detected at GM，地址为成对的 0x1201a2200000、0x1201a2240000…（间隔 0x40000），两事件分属 aiv-0/aiv-1（同物理核双 vector）。
5. 查看工具日志 mindstudio_sanitizer_log/mssanitizer_*.log：blockDim:28、aic 0-27 / aiv 0-55，确认同一 GM 地址由同一物理核的两个 AIV 各自 ClearWorkspace 写入。

Describe the expected behavior / 预期结果 (Mandatory / 必填)

预期结果

• ClearWorkspace 的 GM workspace 清零应在 Ascend950 双 AIV 场景下正确处理，建议二者之一：
  1. 清零只由 sub-block0 执行，sub-block1 经核间 flag 同步等待（例如 if (GetSubBlockIdx() == 0) ClearWorkspace(...)，再配合 CrossCoreSetFlag/WaitFlag 让双 AIV 对齐）；或
  2. 清零按 sub-block 拆分到各自独立子区域，并在双 AIV 之间加显式 AIV 间同步指令。
• 已在本工作区本地验证：采用方案 1（清零仅 sub-block0 + 双 AIV 核间 flag 屏障 CrossCoreSetFlag<0, PIPE_MTE3>/CrossCoreWaitFlag，新 flag id=13）后重编重跑：
  • racecheck：WAW 由 28 条降为 0（No error detected）；
  • example 输出 gradWeight=686.0，与修复前一致（无死锁、功能正确）。
• 修复建议由算子开发者评审后合入（当前为本地验证性修改，需按仓内流程提交）。

Related log / screenshot / 日志 / 截图 (Mandatory / 必填)

见附件：
81_conv3d_backprop_filter_v2.zip

Special notes for this issue/备注 (Optional / 选填)