【合入来源】

如有社区issue，请关联issue链接
请勿携带内部流程信息（需求链接、问题单、内部issue等）

• 需求
• 问题单
• issue/工单
• 重构优化
• 资料更新

【修改方案】

0.修改不完整，需要同https://gitcode.com/Ascend/pytorch/pull/32307一起修改

1. 现象与背景 (Background)

在模型的测试中，遇到一个涉及 NPU Triton Codegen 的编译错误。
用户测试用例（如 test_factory_reduction.py）中包含了一个“没有任何显式数据输入加载（Load）操作，只包含常量生成及归约（Reduction）计算”的网络结构。
核心计算模式类似于：

full_tensor = torch.ops.aten.full.default(shape, 1.0, dtype=dtype_val, layout=torch.strided, device='npu', pin_memory=False)
result = torch.ops.aten.amax.default(full_tensor, [2])

这种类型的归约计算在 Inductor 内部被称为 Factory Reduction。

在尝试编译运行此结构时，触发了多连串的报错。

2. 错误一：assert gold must have same length as tiling_axis

2.1 报错现象

首先遇到的错误是 RuntimeError("assert gold must have same length as tiling_axis")，发生在 pytorch\torch_npu\_inductor\codegen\kernel_analysis.py#L191。

2.2 根因分析

在 Triton 核心代码生成的 select_golden_varlist 函数中，用于推导输出形状对应的 golden_var_list（黄金变量列表）时，其底层逻辑强依赖于访存索引（load_store_indexing）。
由于这是一个 Factory Reduction，没有 tl.load 操作，唯一产生的 load_store_indexing 是最终输出结果的 tl.store 索引。
在这个用例中，因为执行了对最后一维（例如 r1 对应维度 [2]）的归约，输出结果的维度只与保留的非归约轴（如 x0）有关，所以 store_index 中只包含 [x0]，没有 r1。
导致解析出的 golden_var_list 仅为 [x0]。但是当前 Kernel 定义的 tiling_axis 包含了所有的循环轴（即 [x0, r1]）。
当进入 kernel_analysis.py 进行后续分析时，校验 golden_var_list 长度和 tiling_axis 长度不一致，从而引发报错。

2.3 修复方案

修改 pytorch\torch_npu\_inductor\codegen\triton.py 中的 select_golden_varlist 逻辑。
在通过原始机制获取到 golden_var_list 后，增加对齐逻辑：遍历 self.tiling_axis，若有未被包含的轴，则主动补齐到 golden_var_list 的末尾，确保二者长度一致。

        if self.golden_var_list is not None and self.tiling_axis:
            golden_list = list(self.golden_var_list)
            for x in self.tiling_axis:
                sym = x.symbol() if hasattr(x, 'symbol') else x
                if sym not in golden_list:
                    golden_list.append(sym)
            self.golden_var_list = tuple(golden_list)

3. 错误二：生成的代码中 NameError('x0 is not defined')

3.1 报错现象

修复错误一后，生成了 Triton 源代码（output code），但在执行时报错：NameError('x0 is not defined')。
经过检查生成的代码，发现虽然存在 for loop_x0 in range(loops_x0): 的循环体，但是循环内部至关重要的 x0 = ... 和 x0_mask = ... 等变量定义丢失了。

3.2 根因分析

通过大量的日志追踪生成的 indexing_code 的生命周期，我们发现导致 x0 丢失的有两个阶段的问题：

问题阶段 A：find_axis_in_load_store 判定过严

在判断某个循环轴（如 x0）是否被用到时，原有的 find_axis_in_load_store 函数只在代码行中搜索包含了 'tl.load' 或 'tl.store' 字符串的情况：

        for line in self.compute._lines:
            if line.find('tl.load') >= 0 and self.is_isolated_symbol(line, range_val):
                return True

因为这是 Factory Reduction，计算块（compute buffer）中全是 tmp0 = 1.0，tl.broadcast_to 和 tl.max，没有 tl.load，导致即使 x0 在 post_loop_store 被用到，也被错误地判定为 False。
修复：删除了对 tl.load 和 tl.store 的硬性字符串匹配，只要相关缓冲池（loads, compute, stores, post_loop_store）的代码行中出现了该独立符号，即判定为 True。

问题阶段 B：外层粗暴的空校验拦截

即使修复了上述阶段 A，日志显示 x0 还是未被定义。最终通过分析代码发现，在 codegen_body 内部嵌套的 codegen_range 函数的最外层，有一段致命的判断：

            indexing_code = getattr(range_val, "indexing_code")
            # ...
            # do nothing except for writing porintwise
            if len(self.loads._lines) == 0 and len(self.stores._lines) == 0:
                do_indent = False
                indexing_code = None  # <--- 这里是罪魁祸首！

由于没有 Load，且此用例的 Store 全部被放在了 post_loop_store 缓冲池中（导致 self.stores 也为空），这段逻辑强制触发，直接把 _codegen 生成的包含 x0 = ... 的 indexing_code 清空成了 None。

3.3 修复方案

方案

彻底移除了 codegen_range 最外层的那个基于 loads 和 stores 的粗暴空校验拦截逻辑。
让是否生成并输出 indexing_code 完全交由下方各分支内更严谨的 find_axis_in_load_store(range_val) 来决定。

【资料变更】

“不涉及”

【接口变更】

“不涉及”

【功能验证】

增加用例，验证通过

【CheckList】

PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x]

• 代码注释完备，正确记录错误日志
• 代码实现进行了返回值、空指针等校验
• PR标题正确使用类型标签，如：feat、fix、refactor、docs、test等
• PR持续集成流水线（CI）执行通过，代码检查无异常