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

一、问题描述 （必填）

InvGrad 在 Ascend950 转测准入检查中存在以下问题：

1. op_graph/inv_grad_proto.h 中的 REG_OP(InvGrad) 未增加 OPS_PROTO_DEF_INVGRAD 宏保护。按照当前原型整改规则，不再删除重复定义，而是需要通过统一宏保护避免头文件组合使用时重复展开原型定义。

2. Ascend950 AI Core dtype 仍通过 Tiling 模板参数驱动：

   • Kernel 侧声明 ASCENDC_TPL_ARGS_DECL、ASCENDC_TPL_SEL；
   • Host Tiling 侧调用 ASCENDC_TPL_SEL_PARAM；
   • Kernel 入口继续使用 C++ 模板类型参数。

   该实现不符合 ops-transfer-test-scan 的 def 驱动 dtype 要求。InvGrad 已在 inv_grad_def.cpp 中声明 FP32、FP16、BF16、INT32 四组 dtype profile，应由构建系统注入 DTYPE_X 并分别生成 Kernel binary，不应再使用 dtype TilingKey 分派。

上述问题会导致转测准入检查不通过，并使 Host UT 依赖框架编码的 dtype TilingKey 数值。

二、环境信息 （可选）

• 昇腾硬件型号：Ascend950DT_9592
• CANN版本：9.2.0
• 操作系统：Ubuntu 20.04 x86_64

三、重现步骤 （可选）

1. 切换到上述代码基线。
2. 检查 InvGrad 原型定义
3. 检查 dtype TilingKey：rg -n "ASCENDC_TPL_ARGS_DECL|ASCENDC_TPL_SEL|ASCENDC_TPL_SEL_PARAM" math/inv_grad
4. 按 ops-transfer-test-scan 流程扫描 InvGrad 的旧 Tiling 注册与 def 驱动 dtype 项。

四、预期结果 （可选）

REG_OP(InvGrad) 使用 OPS_PROTO_DEF_INVGRAD 宏保护。
dtype 完全由 inv_grad_def.cpp 的 DataType profile 驱动。
Kernel 使用构建系统注入的 DTYPE_X。
Host 不再设置 dtype TilingKey，四种 dtype 的运行时 TilingKey 均为 0。
Ascend950 分别生成 FP32、FP16、BF16、INT32 四个 Kernel binary。
Host UT、Kernel 构建及算子精度测试全部通过。

💡 备注（选填）