🔵 [优化] aclnnTransposeBatchMatMul.md 文档中 950PR/950DT 平台的 permX2 支持范围与 A2/A3 不一致

文件: matmul/transpose_batch_mat_mul/docs/aclnnTransposeBatchMatMul.md

文档中：

• A2/A3 平台：permX2 支持 [0,1,2]、[0,2,1]（本次 PR 新增）
• 950PR/950DT 平台：permX2 支持 [0,1,2]、[0,2,1]（原有支持）

但代码中 CheckPermLimit 已经移除了 DAV_3510 的平台判断，统一支持 [0,1,2] 和 [0,2,1]。这意味着文档中 950PR/950DT 的 permX2 支持描述与代码一致，但 A2/A3 的约束条件（不支持 scale、batchSplitFactor=1、permX1=[1,0,2]）在 950PR/950DT 上是否同样适用？文档中未明确说明。

建议: 在文档中明确 950PR/950DT 平台使用 permX2=[0,2,1] 时是否有额外约束，避免用户混淆。

为啥不用驼峰？代码风格都不太对的，后需要要统一整改

🔴 [严重] CheckShapeValid 中 x2_need_transpose 使用了 perm_x1 而非 perm_x2

文件: op_api/aclnn_transpose_batch_mat_mul.cpp

auto x2_need_transpose = ((*perm_x1)[0] == 0 && (*perm_x1)[1] == 2 && (*perm_x1)[2] == 1);

此处变量名为 x2_need_transpose，但实际使用的是 perm_x1 而非 perm_x2。如果这是笔误，则 permX2=[0,2,1] 的校验将完全失效，x2 的转置判断实际上检查的是 x1 的 perm 值。

如果意图是"当 x1 的 perm 为 [0,2,1] 时"，则变量名 x2_need_transpose 严重误导，应改为 x1_perm_021 或类似名称。

建议: 确认此处语义：

• 如果是笔误，修正为 (*perm_x2)：

auto x2_need_transpose = ((*perm_x2)[0] == 0 && (*perm_x2)[1] == 2 && (*perm_x2)[2] == 1);

• 如果是有意为之（即"当 x1 perm 为 [0,2,1] 时触发 x2 转置限制"），则必须更改变量名避免混淆。

🟡 [建议] pp_matmul_common_tiling.h 运算符优先级修复正确，但建议增加单元测试

文件: op_host/op_tiling/pp_matmul_common_tiling.h

// 修改前（运算符优先级错误）:
platformType == platform_ascendc::SocVersion::ASCEND910 && basicBlockSize > UB_LIMIT_SIZE_910A ||
platformType == platform_ascendc::SocVersion::ASCEND310P && isPertokenArch20 == true && 
basicBlockSize > UB_LIMIT_SIZE_PERTOKEN_ARCH20

// 修改后（正确添加括号）:
(platformType == platform_ascendc::SocVersion::ASCEND910 && basicBlockSize > UB_LIMIT_SIZE_910A) ||
(platformType == platform_ascendc::SocVersion::ASCEND310P && isPertokenArch20 == true && 
basicBlockSize > UB_LIMIT_SIZE_PERTOKEN_ARCH20)

修复正确！原代码中 && 和 || 的优先级导致逻辑错误：A && B || C && D 被解析为 (A && B) || (C && D)，恰好与预期一致，但如果 isPertokenArch20 条件更复杂则可能出错。添加括号使意图更明确。

建议: 此类运算符优先级 bug 应添加单元测试覆盖，确保在不同 platformType 和 basicBlockSize 组合下 IsExceedTilingLimit 返回正确结果。

🔵 [优化] transpose_batch_mat_mul_base_tiling.cpp 移除 support_k_n 校验后，错误信息可能不够准确

文件: op_host/op_tiling/transpose_batch_mat_mul_base_tiling.cpp

// 修改前:
OP_TILING_CHECK(!(support_k_n && support_batch_m), CUBE_INNER_ERR_REPORT(args_.opName,
    "only support shape inner axis < 65536, input shape b, m, n, k = %lu, %lu, %lu, %lu.",
    input_batch, args_.mValue, input_n, input_k), return ge::GRAPH_FAILED);

// 修改后:
OP_TILING_CHECK(!support_batch_m, CUBE_INNER_ERR_REPORT(args_.opName,
    "only support shape inner axis < 65536, input shape b, m, n, k = %lu, %lu, %lu, %lu.",
    input_batch, args_.mValue, input_n, input_k), return ge::GRAPH_FAILED);

移除 support_k_n 校验（即 K/N 不再要求 16 对齐）是本次 PR 的核心改动之一。但错误信息 "only support shape inner axis < 65536" 仍然保留，可能让用户误以为 K/N 对齐仍是限制条件。

建议: 更新错误信息，使其准确反映当前的约束条件，例如 "only support batch * m < 65536 for transposed input".

🟡 [建议] CheckInputArgs 与 IsPpMatmulEinsumMode 存在重复的 attrs 校验逻辑

文件: op_host/op_tiling/transpose_batch_mat_mul_einsum_tiling.cpp

CheckInputArgs 函数校验了：

• bias/scale 不存在
• enableHF32=false
• batchSplitFactor=1

IsPpMatmulEinsumMode 在调用 CheckInputArgs 之后，又独立校验了 permX1=[1,0,2]。

但 CheckInputArgs 中的 bias/scale 校验与 IsPpMatmulEinsumMode 中 B*K>65535 场景的限制（不支持 scale、batchSplitFactor=1、permX1=[1,0,2]）语义重叠但不完全一致。

建议:

• 将 CheckInputArgs 合并到 IsPpMatmulEinsumMode 中，或将其重命名为更明确的名称如 CheckEinsumBasicConstraints
• 在 IsPpMatmulEinsumMode 中增加注释，说明不同分支（B*K>65535 vs permX2=[0,2,1] vs FP32）各自需要满足的约束条件

🟡 [建议] IsPpMatmulEinsumMode 中 K >= SUPPORTED_INNER_AXIS 条件判断与文档不一致

文件: op_host/op_tiling/transpose_batch_mat_mul_einsum_tiling.cpp

if (K >= SUPPORTED_INNER_AXIS || Batch * K >= SUPPORTED_INNER_AXIS) {

SUPPORTED_INNER_AXIS = 65536，所以 K >= 65536 等价于 K > 65535。但文档中写的是"K <= 65535"（即 K 最大为 65535），而 CheckShapeValid 中是 x1KDim >= SUPPORTED_INNER_AXIS（即 K >= 65536 时报错）。

在 IsPpMatmulEinsumMode 中，K >= SUPPORTED_INNER_AXIS 意味着当 K >= 65536 时路由到 Einsum 模式。但根据文档，K > 65535 时应该报错而非路由到 Einsum。

建议: 确认 K >= 65536 是否为合法场景。如果 K 的上限确实是 65535，则 IsPpMatmulEinsumMode 中 K >= SUPPORTED_INNER_AXIS 这个条件永远不会为真（因为 CheckShapeValid 已经拦截），可以移除或添加注释说明这是防御性编程。

🔴 [严重] IsPpMatmulEinsumMode 中 B*K>65535 时直接路由到 Einsum，但未校验 scale/batchSplitFactor 限制

文件: op_host/op_tiling/transpose_batch_mat_mul_einsum_tiling.cpp

if (K >= SUPPORTED_INNER_AXIS || Batch * K >= SUPPORTED_INNER_AXIS) {
    OP_LOGI(context->GetNodeName(), "When K > 65535 or Batch*K > 65535, hit PpMatmulEinsum.");
    return ge::GRAPH_SUCCESS;  // 直接进入 Einsum 模式
}

当 Batch * K >= 65536 时，IsPpMatmulEinsumMode 直接返回 GRAPH_SUCCESS 路由到 Einsum tiling。但根据 PR 描述和 CheckShapeValid 中的约束，当 B*K > 65535 时，不支持传入 scale，且 batchSplitFactor 只能等于 1，permX1 必须为 [1,0,2]。

然而 IsPpMatmulEinsumMode 在此分支中没有校验 scale 和 batchSplitFactor。虽然 CheckInputArgs 中校验了 bias/scale 为空和 batchSplitFactor=1，但 CheckInputArgs 是在 IsPpMatmulEinsumMode 内部被调用的——如果 CheckInputArgs 返回 GRAPH_FAILED，则整个 IsPpMatmulEinsumMode 也返回 GRAPH_FAILED，不会进入 Einsum 模式。

但问题在于：CheckInputArgs 中对 scale 的校验是 GetOptionalInputShape(INDEX_SCALE) != nullptr，这只检查了 scale 是否存在，没有检查 permX1 是否为 [1,0,2]。如果用户传入 B*K>65535 + scale=nullptr + permX1=[0,1,2]，CheckInputArgs 会通过，但 CheckShapeValid 会拒绝——两个路径的校验逻辑不一致。

建议: 在 IsPpMatmulEinsumMode 的 B*K>65535 分支中，增加 permX1=[1,0,2] 的校验，确保 tiling 路由和 API 层校验一致。

🟡 [建议] GetCloseKShiftFlag 使用环境变量 CLOSE_MATMUL_K_SHIFT 控制功能开关，存在安全风险

文件: op_host/op_tiling/transpose_batch_mat_mul_einsum_tiling.cpp

const char* closeKShiftFlag = std::getenv("CLOSE_MATMUL_K_SHIFT");
if (closeKShiftFlag != nullptr && strcmp(closeKShiftFlag, "1") == 0) {
    return true;
}

通过环境变量控制算子行为存在以下问题：

1. 不可追踪: 环境变量是运行时外部状态，难以在日志或调试中追踪
2. 并发不安全: 多个算子实例共享同一环境变量，无法对不同算子设置不同行为
3. 安全风险: 恶意用户可通过设置环境变量改变算子计算行为

建议:

• 如果此开关仅用于调试/测试，添加注释说明不应在生产环境使用
• 如果需要长期保留，考虑通过 op_attr 或 context 传入而非环境变量
• 至少添加 OP_LOGW 警告日志，提示环境变量已被设置

🟡 [建议] PostTiling 中 workspace 大小硬编码为 24MB，缺乏依据说明

文件: op_host/op_tiling/transpose_batch_mat_mul_einsum_tiling.cpp

size_t sysWorkspaceSize = static_cast<size_t>(24 * 1024 * 1024);  // 24M same as ppmatmul tiling

workspace 大小硬编码为 24MB，注释仅说"same as ppmatmul tiling"。不同场景（B*K>65535、permX2=[0,2,1]）可能需要不同的 workspace 大小。

建议:

• 将 24 * 1024 * 1024 提取为命名常量，如 constexpr size_t EINSUM_DEFAULT_WORKSPACE_SIZE = 24UL * 1024 * 1024;
• 补充注释说明 24MB 的计算依据（是否与最大 batch/K 组合相关）
• 考虑是否需要根据实际输入 shape 动态计算 workspace 大小