[VPTO] PTODSL 默认 kernel_kind 被序列化为显式 kind，导致 C/V split 冲突

[jimmychou0]

背景与目标

TileLang 正在将手写 AIC/AIV GEMM 示例 examples/ascend/example_gemm_mix_manual.py 迁移到 VPTO 路径的 PTODSL。迁移入口需要支持未显式指定 kernel_kind 的 @pto.jit(..., backend="vpto")：同一 entry 中的 Vector TileOp 和 Cube TileOp 应被 VPTO 分别编译为 Vector 与 Cube child。

本 issue 不建议引入 kernel_kind="mixed"。PTODSL 现有默认值 module_spec.kernel_kind="vector" 及其 kernel_kind_explicit=False 需要继续保留，供 native build 决定 host 编译架构；问题在于该默认值不应被当作用户写入 PTO IR 的显式 kernel kind。

复现 POC

下面的 POC 使用真实 pto.tileop()，故 PTODSL 会根据 TileOp 自动形成 pto.section.vector 与 pto.section.cube。它有意没有传入 kernel_kind=：

from ptodsl import pto

@pto.jit(name="default_kind_cv_tileop_probe", target="a5")
def default_kind_cv_tileop_probe():
    with pto.tileop():
        zero = pto.const(0, dtype=pto.i64)
        source = pto.castptr(zero, pto.ptr(pto.f32, "ub"))
        destination = pto.castptr(zero, pto.ptr(pto.f32, "ub"))
        value = pto.vlds(source, 0, pto.vreg_type(64, pto.f32))
        pto.vsts(value, destination, 0, pto.pset_b32(pto.MaskPattern.ALL))

    with pto.tileop():
        zero = pto.const(0, dtype=pto.i64)
        lhs = pto.castptr(zero, pto.ptr(pto.f16, "left"))
        rhs = pto.castptr(zero, pto.ptr(pto.f16, "right"))
        acc = pto.castptr(zero, pto.ptr(pto.f32, "acc"))
        extent = pto.const(16, dtype=pto.i64)
        pto.mad(lhs, rhs, acc, extent, extent, extent)

该 POC 用于隔离 PTODSL trace 与 C/V split，不是完整可执行的 VPTO kernel：其中 pto.vlds 尚未放入合法的 pto.vecscope。这不会影响对 split 的观察，因为默认路径在到达 vector verifier 前已于 split pass 失败。

已验证的实际行为

在上游 main 的 d852dd2 上：

1. pto.jit 在省略 kernel_kind 时正确保留 module_spec.kernel_kind="vector"，并标记 kernel_kind_explicit=False。

2. ptodsl/ptodsl/_tracing/module_builder.py::_apply_child_module_attrs 没有检查 kernel_kind_explicit。因此它仍将默认值写入 backend child：

   module attributes {pto.backend = "vpto",
                      pto.kernel_kind = #pto.kernel_kind<vector>} {
     func.func @default_kind_cv_tileop_probe() attributes {pto.entry} {
       pto.section.vector { ... }
       pto.section.cube { ... }
       return
     }
   }

3. VPTOSplitCVModule 将这个 pto.kernel_kind<vector> 当作显式 authored intent。在同一 module 内发现 pto.section.cube 后，verifyExplicitKernelKindMatchesSections 直接报错并终止 emission：

   error: conflicts with explicit pto.kernel_kind on its module
   Error: VPTO emission pipeline failed.
   

因此此前“只生成 vector child、未生成 cube child”的结论不准确。实际是 C/V split 在冲突校验阶段失败，不会产生可继续使用的单 vector 输出。

单变量对照

仅手工删除真实生成 .pto 的 backend child pto.kernel_kind<vector> 属性，不改动任何 operation 或 section：

• VPTOSplitCVModule 成功拆出一个 vector child 与一个 cube child；
• 两个 child 分别保留对应的 vector/cube 指令；
• split 之后才因 POC 中 pto.vlds 缺少 pto.vecscope 触发独立的 vector verifier 错误。

这证明现有 split pass 已能处理“无 kind 的 backend-partitioned child 含 C/V section”这一形态。本 issue 的失败由前端把默认值错误物化为 IR 属性引起。

期望语义与修复边界

PTODSL tracing 应区分运行时默认值和用户显式语义：

1. 默认路径继续保留 module_spec.kernel_kind="vector" 和 kernel_kind_explicit=False，不改变 native build 的选择逻辑。
2. 仅当用户显式传入 kernel_kind=，即 kernel_kind_explicit=True 时，_apply_child_module_attrs 才向 PTO IR backend child 写入 pto.kernel_kind。
3. 默认且同时有 Cube/Vector section 的 backend child 不带 pto.kernel_kind；现有 VPTOSplitCVModule 据此 materialize 出 Cube 和 Vector 两个 child。
4. 显式 kernel_kind="cube" 或 kernel_kind="vector" 继续保持现有的单-kind 行为。

针对这个默认-kind 冲突，不需要先改动 PTOAS 后端 split pass；首要修改点是 PTODSL module_builder.py 的 child 属性写入条件。

影响与回归

该问题阻塞手写 Cube+Vector GEMM 的 VPTO 迁移：默认 entry 无法通过 C/V split，因此不能进入后续 L0C 到 UB、AIC/AIV 同步和代码生成验证。纯 Cube GEMM 与 PTOGemmL1Template 不受此问题影响。

回归应使用一个补齐 pto.vecscope 的合法 TileOp POC，至少覆盖：

1. 未显式 kernel_kind 且同时含 C/V section：trace child 无 pto.kernel_kind，--emit-vpto 产生一个 Cube child 和一个 Vector child；
2. 显式 kernel_kind="vector"：仍只 materialize Vector；
3. 显式 kernel_kind="cube"：仍只 materialize Cube。

环境

复核基线：PTOAS upstream main commit d852dd2，VPTO A5 emission。上述结论基于生成 PTO IR、split pass IR dump 及单变量去属性对照。

[jimmychou0]

推荐的 PTOAS 修改方案：复用并扩展自动 section 推导

建议采用“自动推导”而不是新增公开的 PTODSL section hint 接口。但实现位置应是 PTOAS 对 PTODSL 生成 IR 的 pre-backend normalization，不是 Python tracing 层重新发明一套 section API。

已验证的现有边界

上游 main 已有两条相关 pass，且均在 VPTO split 前运行：

• PTOMaterializeTileOpSectionsPass：只处理 pto.tileop.helper，为纯 Vector 或纯 Cube helper 推导并物化一个 section；它明确拒绝 MTE、pipe sync 和高层 TileOp。
• PTONormalizeUncoveredTileSectionsPass：能为未包裹的高层 TileOp 段按 TileOp 名称、pipe、Tile 地址空间推导 section。

这两条能力不能直接覆盖 TileLang 手写 mixed GEMM 的 codegen 输出。该路径包含 raw VPTO vector micro-op、MAD、MTE 及 flag/sync，而不是纯 pto.tileop.helper 或高层 pto.tload/tmatmul/tstore 序列。

对一个不带 pto.kernel_kind、也不带 pto.section.*、同时含 pto.vlds/pto.vsts 与 pto.mad 的最小 raw C/V POC，当前 --emit-vpto 输出只有一个 pto.kernel_kind<vector> child，且其中仍保留 pto.mad_raw。因此现有 normalization 会把 raw vreg 当成 whole-module Vector 证据，却没有将 raw C/V 分段并物化为两个 section。这是本方案要修复的错误基线。

1. 修正默认 kernel kind 的 IR 物化

修改 ptodsl/ptodsl/_tracing/module_builder.py::_apply_child_module_attrs：

• 保留 module_spec.kernel_kind="vector" 和 kernel_kind_explicit=False，供 native build 使用；
• 仅在 kernel_kind_explicit=True 时向 backend child 写 pto.kernel_kind；
• 默认 mixed child 保持无 kind，允许后续 normalization 和 C/V split 工作。

2. 扩展 PTONormalizeUncoveredTileSectionsPass 的 raw C/V 推导

在现有高层 TileOp 推导之外，增加针对 raw VPTO 指令的保守分段路径：

1. 调整 pass 顺序内部逻辑：先对 raw 指令做 section 分段，后尝试 whole-function / whole-module 单 kind 推导。不能再因发现一个 !pto.vreg 就抢先把含 Cube 指令的 child 固化为 vector。
2. 增加 physical-kind evidence 分类：
   • Cube：mad/mad_raw、Cube micro-op、L0A/L0B/L0C 相关计算，以及能由地址空间唯一判定的 Cube MTE；
   • Vector：!pto.vreg/!pto.mask/!pto.align、Vector micro-op，以及能由地址空间或 pipe 唯一判定的 Vector MTE；
   • neutral：标量、arith、地址计算、结构化控制流、分配，以及无法单独决定 AIC/AIV ownership 的同步。
3. 分段与物化规则：对 function 顶层连续 raw 段收集 evidence；单一 kind 段连同其可唯一归属的 neutral operation 一起包入 pto.section.cube 或 pto.section.vector。控制流需递归汇总，不能把同一 loop/branch 内的 C/V evidence 静默混为一个 section。
4. 同步的保守处理：FIX / MTE3 flag 或 cross-core sync 仅在 pipe 语义和相邻段共同给出唯一归属时随该段移动；在 Cube/Vector 边界仍无法判定的同步必须报出“section kind ambiguous”，而不是按默认 vector 猜测。
5. 失败语义：未覆盖 raw op、混合 evidence、或不能唯一归属的中性区间应给出定位到首个冲突 operation 的诊断。不能为了让流程继续而写入默认 pto.kernel_kind<vector>。

3. 不修改 VPTOSplitCVModule

无 kind backend-partitioned child 已经含有 pto.section.cube 和 pto.section.vector 时，现有 VPTOSplitCVModule 可以产生两个 kind child。此前的单变量对照已验证这一点。

因此本 issue 不需要先修改 split pass；新的 normalization 负责在 split 之前提供正确、无 kind 的 sectioned IR。

4. 回归覆盖

新增 VPTO lit / PTODSL-to-VPTO 回归：

1. 默认、无 child kind 的 raw C/V POC：--emit-vpto 恰好得到一个 Cube child 和一个 Vector child，Cube child 保留 MAD，Vector child 保留 vreg 指令；
2. raw pure Cube 与 raw pure Vector：仍只得到对应的一个 child；
3. 显式 kernel_kind="cube" / "vector"：保留单-kind 行为；
4. raw C/V evidence 无法唯一分段、或 sync 位于不可判定边界：必须报诊断，不能静默归为 vector；
5. 后续接入 example_gemm_mix_manual.py 的生成 PTO IR，检查 C/V section、L0C->UB、UB->GM 与 AIC/AIV sync 的 split 后归属。

这一路径不需要引入 kernel_kind="mixed"，也不需要把物理 section hint 暴露为新的 PTODSL 用户 API。