Pull Request

描述

本次 Pull Request 针对 Norm 类计算中的通用性能问题进行优化，重点覆盖固定输入重复处理、同源 Broadcast 重复计算以及归约后 Elementwise API 碎片化等场景。

本次变更不匹配固定的 LayerNorm 完整 Pattern，也不依赖特定 Shape、节点名称或前端算子名称，而是根据图结构、Tensor View 和调度属性识别可优化的局部计算。当前主要以 LayerNorm 作为功能和性能验证对象。

主要变更如下：

1. 统一固定输入缓存逻辑

重构 Kernel Loop Codegen 中的缓存条件判断与 cache guard 生成流程：

• 统一 Reduce 图和非 Reduce 图的缓存资格判断。
• 支持 Origin、Fused 等缓存刷新方式。
• 支持双 Tile Reduce 场景下的 A/R 刷新条件。
• 对满足条件的固定输入 Load/Broadcast 链，仅在缓存刷新点重新生成结果。
• 后续 Tile 迭代复用 UB 中已有的 LocalTensor，减少重复数据搬运和 Broadcast。
• 无法证明输入在缓存周期内保持不变时，保留原执行路径。

2. 新增同源 Broadcast CSE Pass

新增面向 Norm-like 图的同源 Broadcast 公共子表达式消除能力：

• 收集来自实际降维 Reduce 输出的 Broadcast 节点。
• 按相同输入源对候选 Broadcast 分组。
• 比较 dtype、axis、repeats、strides、vectorized view 和调度属性。
• 检查控制依赖、消费者顺序和 Tensor 生命周期安全性。
• 对满足等价和安全条件的 Broadcast，保留拓扑较早的节点。
• 将重复 Broadcast 的消费者重连到保留节点，并删除重复节点。
• View、调度或生命周期条件不满足时不执行合并。

该 Pass 已注册到 v35 GraphPassRunner，在 Tensor View 和调度属性稳定后、VF 分区前执行。

3. 支持归约后 Elementwise VF 融合

扩展 Rsqrt 和 TrueDiv 的 VF 能力，使 LayerNorm 等场景中的归约后 Elementwise 链能够连续执行：

• 新增 MicroRsqrtApiCall。
• 使用 RegBase 基础指令组合实现 Rsqrt 计算。
• 为 Rsqrt 开启 VF 能力。
• 支持合法场景下的 TrueDiv -> Add -> Rsqrt 连续 VF 路径。
• 减少中间 Tensor、UB 读写、同步和独立 API 边界。
• 保持 FP32 TrueDiv 的高精度除法模式。
• View、stride、dtype 或资源条件不满足时，继续使用原有 API 路径。

4. 补充功能验证与回退场景

针对上述优化补充了以下测试能力：

• 固定输入缓存条件和 cache guard 生成验证。
• 双 Tile Reduce 缓存刷新条件验证。
• 同源等价 Broadcast 合并验证。
• View、调度、控制依赖或 Reduce 条件不满足时的回退验证。
• MicroRsqrt 代码生成和异常值处理验证。
• TrueDiv -> Add -> Rsqrt VF 分区和生成结果验证。
• 通过完整 GraphPassRunner 验证 Broadcast CSE 的注册、执行和图重连结果。

5. 重构日志和测试代码

• 调整同源 Broadcast CSE 文件命名，使其符合 GraphPass 命名习惯。
• 将测试中的重复图构造逻辑提取为辅助函数。
• 优化长日志语句的排版。
• 清理冗余引用并调整测试代码结构，提高可读性和可维护性。

变更类型

请选择本次引入的变更类型：

• 🐛 Bug 修复
• ✨ 新功能
• 💄 代码风格更新（格式化，局部变量）
• ♻️ 重构（既不修复错误也不增加功能的代码变动）
• 📦 构建过程或辅助工具的变动
• 📝 文档内容更新

关联的 Issue

暂无。

如何测试

测试前提

• 使用支持 v35 后端的 CANN 环境。
• 使用 A5/Ascend 950 目标设备。
• 开启 LayerNorm 到融合后端的执行路径。
• 使用相同输入分别执行 LayerNorm 单算子和融合 Kernel。

测试步骤

1. 执行 LayerNorm 端到端功能测试

   • 覆盖不同外轴大小和归约长度。
   • 覆盖完整块和尾块场景。
   • 覆盖 FP16、BF16 和 FP32。
   • 覆盖 gamma+beta、仅 gamma、仅 beta和无仿射参数等输入形态。

2. 验证计算结果

   • 对比融合 Kernel、LayerNorm 单算子和参考实现的结果。
   • 检查最终输出以及均值、方差和 rstd 等中间统计量。
   • 根据不同 dtype 使用对应的误差标准。
   • 覆盖全零、全相同值、NaN、正负 Inf、极大值和极小值等特殊输入。
   • NaN 结果按照传播位置和范围比较，不使用普通数值误差直接判断。

3. 验证固定输入缓存

   • 选择带 gamma、beta 且包含多次 Tile 迭代的 LayerNorm 场景。
   • 检查生成 Kernel，确认固定输入的 Load/Broadcast 链受正确的 cache guard 控制。
   • 确认结果仅在缓存刷新点重新生成，其他迭代复用 UB 中已有的 LocalTensor。
   • 验证普通缓存周期、融合广播周期和双 Tile Reduce 刷新周期。
   • 对比优化前后结果，确认不存在未初始化读取或跨周期错误复用。

4. 验证同源 Broadcast CSE

   • 构造同一个 Reduce 统计量产生两个等价 Broadcast 的 LayerNorm 图。
   • 检查优化后的 Dump 图，确认等价 Broadcast 只保留一个。
   • 确认原有消费者均连接到保留节点。
   • 执行优化后的 Kernel，并与优化前结果进行对比。
   • 使用 View 不同、调度不同或存在控制依赖的图验证安全回退，确认不满足条件的 Broadcast 不会被合并。

5. 验证归约后 Elementwise VF

   • 使用包含 TrueDiv -> Add -> Rsqrt 统计量后处理链的 LayerNorm 场景。
   • 检查优化后的图和生成 Kernel，确认合法场景中的连续 Elementwise 节点进入同一个 VF。
   • 检查 FP32 TrueDiv 仍使用高精度除法模式。
   • 验证 Rsqrt 对负数、零值和正常输入的处理与原路径一致。
   • 使用 View、stride、dtype 或资源条件不满足的场景验证原 API 路径能够正常回退。

6. 验证性能

   • 在目标设备上使用相同输入分别运行 LayerNorm 单算子和融合 Kernel。
   • 覆盖多个外轴大小、归约长度和尾块场景，避免使用单一 Shape 判断收益。
   • 使用设备侧 Task Duration(us) 作为性能指标。
   • 确认优化后不存在明显性能回退。
   • 目标为融合 Kernel 达到对应 LayerNorm 单算子性能的 95% 以上，或两者耗时差小于 2 us。

预期结果

• 优化前后 LayerNorm 计算结果满足对应 dtype 的精度要求。
• 固定输入仅在正确的缓存刷新点重新生成。
• 同源且等价的 Broadcast 被安全合并。
• 不满足等价或生命周期条件的 Broadcast 保持不变。
• TrueDiv -> Add -> Rsqrt 在合法条件下进入同一个 VF。
• 任一优化条件不满足时均能够稳定回退到原路径。
• 优化逻辑不依赖固定 Shape 白名单。

核对清单

• 我的代码遵循了项目的代码风格
• 我已对代码进行了自测
• 我已更新了相关的文档
• 我在标题中使用了合适的类型标签（如：feat:, fix:）
• 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于 commit message 的格式、无效 commit 的合并等

其他信息

• 本次优化按照 Norm 类图的共性结构设计，当前主要以 LayerNorm 作为功能和性能验证对象。
• 固定输入缓存、同源 Broadcast CSE 和归约后 Elementwise VF 是相互独立的优化能力。
• 任一优化条件不满足时，不影响其他优化执行，并保留对应原始路径。
• 优化判断基于图结构、Tensor View 和调度属性，不包含固定 Shape、固定节点名称或前端算子名称白名单。