提交提案之前，请先检索仓库内是否已有相同的提案，如已有请在同一提案中进行讨论。

性能优化具体描述

场景

• 模型：TorchBench Background_Matting
• 模式：推理，batch size 1
• 编译方式：torch.compile(..., backend="inductor", options={"npu_backend": "triton_experimental"})

问题现象

模型中的反射填充和双线性插值在 NPU triton_experimental 后端会沿用通用 Inductor decomposition：

• reflection_pad2d / reflection_pad2d_backward 被展开为通用索引计算；
• upsample_bilinear2d / upsample_bilinear2d_backward 被展开为通用插值计算。

上述算子已有 NPU 原生实现。通用分解路径会在大尺寸空间特征图上增加索引计算、访存和 kernel 调度开销，未能利用原生算子的实现与性能优势。

优化方案

1. 仅在 triton_experimental 后端移除上述四个算子的 decomposition，使其保留为 NPU 原生算子。
2. 为 upsample_bilinear2d.vec 补充 dispatcher，兼容 output_size 和 scale_factors，并转发到原生 default 重载。
3. 新增显式 fallback 列表，在 implicit_fallbacks=False 时注册四个 native fallback，避免因算子没有上游 lowering 而编译失败。
4. 新增前反向精度和生成代码回归测试，确保 eager/compile 数值一致且生成代码确实调用原生算子。

对应修复 PR：Ascend/pytorch#44957

验收标准

• 四个空间算子在 triton_experimental 生成代码中走 NPU 原生调用，不再展开为通用 decomposition；
• F.pad(mode="reflect") 和 F.interpolate(mode="bilinear") 的前反向结果与 eager 一致；
• F.interpolate 的 size、scale_factor 两种入口均通过；
• implicit_fallbacks=False 下可正常编译、执行；
• 改动不影响默认 NPU Inductor 后端及其他后端。

性能劣化说明

这是算子执行路径层面的性能劣化：单个原生空间算子被展开为多段通用索引/逐点计算，在 Background_Matting 的大尺寸特征图上放大了额外计算、HBM 访存和 kernel 调度成本，前向与反向均受影响。

当前没有同一软件栈、同一输入下可归因于这四个算子的稳定端到端 A/B 数据，因此不填写未经验证的加速数字。本次修复通过生成代码检查确认执行路径由通用 decomposition 切换为 NPU 原生算子，并以定向前反向测试保证功能正确性；端到端收益以后续统一性能流水线结果为准。

其他相关讨论

• 修复范围仅包含 reflection_pad2d、upsample_bilinear2d 及其 backward 的 NPU triton_experimental 执行路径。
• PR 当前 head：d4b2b35a0339a9ec35f49a0e9a4977c5b0d2be95。
• 本次新增 4 个定向回归用例，实测结果：Ran 4 tests in 2.971s - OK。

环境信息

- 操作系统：Ubuntu 22.04.5 LTS（aarch64）
- 昇腾硬件：Ascend 910B2
- npu-smi：26.0.rc1
- CANN：9.1.0-beta.1
- Python：3.11.15
- PyTorch：2.13.0
- TorchNPU：2.13.0
- Triton：3.2.0
- NPU Inductor 后端：triton_experimental

欢迎加入社区，感谢您对社区的贡献 🎉！