[Feature] Redesign of PTODSL pto.simd/pto.cube/pto.simt subkernel

[Zhendong404]

Summary

当前PTODSL使用pto.simd/pto.simt/pto.cube装饰器来标记subkernel，从而让plan memory/insert sync等pass也能作用于用户自定义的OP，但pto.simt目前被当做另一种用途——用于标记SIMT kernel，这与subkernel的职责是冲突的。

Motivation / use case

• 使用pto.tileop替代原来pto.simd/pto.cube/pto.simt作为subkernel的标识，供用户书写自定义OP
• 让pto.simt专门作为SIMT kernel的装饰器

Proposed API / behavior

No response

Alternatives considered

No response

Additional context

No response

[jimmychou0]

subkernel-as-op 建模：IR 载体形态

目标与示例

为解决 #859，让 pto.tileop 成为统一 custom subkernel 标识，建模为：tile-level IR 上一个以 tile/tensorview/scalar 为 IO、带所属 pipe 摘要的 op，让 PTOInsertSync/PTOPlanMemory 当一等公民处理。用户零参数，pipe 摘要后端自动推导。典型 softmax subkernel 天然跨 pipe：

@pto.tileop
def softmax(out: pto.Tile, x: pto.Tile):
    buf = pto.mte_load(x)          # PIPE_MTE1
    m = pto.vmax(buf)              # PIPE_V
    e = pto.vexp(pto.vsub(m, buf)) # PIPE_V
    s = pto.vsum(e)                # PIPE_V
    r = pto.vdiv(e, s)             # PIPE_V
    pto.mte_store(out, r)          # PIPE_MTE1

@pto.jit
def kernel(out, x):
    softmax(out, x)
    softmax(out, x)            # 复用同一 subkernel

诉求：跨 pipe（MTE1+V）、含搬运与同步、可多次复用、用户不声明 pipe。

关键后端事实（已核对）

• PTOInsertSync/PTOPlanMemory 均 func.walk 全递归进 region。
• InsertSync 已有专门处理 PTODSL subkernel 的机制：PTOIRTranslator.cpp:205-228 lookupPTODSLSubkernelHelper + getPTODSLSubkernelHelperPipe 跨 func.call 解析 callee、读 pto.ptodsl.subkernel_helper role→单 pipe；UpdatePTODSLSubkernelCallInfo（:696-729）把每个 memory operand 保守建模为 read+write、生成 CompoundInstanceElement 进 syncIR。即现有架构已能穿透 call、在 caller 层建依赖插 sync，只是 (a) 单 pipe、(b) 副作用保守。
• pipe 是 op 自带属性（OpPipeInterface::getPipe()）；PTONormalizeUncoveredTileSections.cpp:156-263 inferSegmentKind 已有多维度 pipe/address-space/op-name/dir-mask 归类，但对混合段报错。
• PTOVerifySubkernelPipeContractPass.cpp:39-44 按 role 查单 expected pipe（cube→PIPE_M、simd→PIPE_V、tileop→不校验）。

载体形态：方案 B — named helper + func.call + pipe 摘要属性

复用现有 func.call + 命名 helper + callee 解析机制（已能穿透），把 role→单 pipe 升级为多属性 pipe 摘要，让现有 CompoundInstanceElement 消费多 pipe。

// 复用单一定义
func.func @softmax(%out, %x)
    { pto.ptodsl.subkernel_helper = "tileop",
      pto.tileop.pipe_footprint = [PIPE_MTE1, PIPE_V],
      pto.tileop.compute_domain = "vector",
      pto.tileop.arg_effects = ["write","read"],
      pto.tileop.has_sync = false } {
  %buf = pto.mte_load %x
  %m = pto.vmax %buf
  ...
  pto.mte_store %out, %r
  return
}

func.func @kernel(%out, %x) {
  func.call @softmax(%out, %x)   // 第1次
  func.call @softmax(%out, %x)   // 第2次，复用同一@softmax
}

摘要四属性（后端 PTOInferTileOpSummaryPass 自动推导）：

• pipe_footprint：body 内出现的 pipe 集合（softmax→[MTE1, V]）。复用 inferSegmentKind 的 pipe/address-space/op-name 归类，输出从"判单 kind 报错"改为"收集 pipe"。

• compute_domain：主计算域 vector/cube（唯一，见 MVP 边界）。

• arg_effects：每参数 read/write/readwrite，让 UpdatePTODSLSubkernelCallInfo 从保守全 R+W（:715-716）升级为精确副作用，直接减少多余 sync。

• has_sync：是否含 barrier/wait/set_flag，让 InsertSync 知道 helper 内部已自管同步。

• 优：复用（一份定义多次 call）；现有 UpdatePTODSLSubkernelCallInfo 已穿透 call，只需把读单 role 改读摘要属性即可消费多 pipe——渐进升级，非重做；arg_effects 让 caller 层 sync 从保守变精确。

• 缺：caller 层仍只看摘要（不进 body 看真实数据流），sync 精度上限低于完全内联；要更优需可选内联 opt pass（后置）。

MVP 边界：单主计算域 + 辅助 pipe

现有后端多处假设"一个 helper 对应一个主 section"——PTOVerifySubkernelPipeContractPass.cpp:39（role→单 pipe）、PTOIRTranslator.cpp:217-228（helper→单 pipe）、UpdatePTODSLSubkernelCallInfo 的 CompoundInstanceElement 用单一 *pipe（:723）。故 MVP 约束：

• 允许：一个主计算域（vector 或 cube）+ 多辅助 pipe（MTE/S/sync）。如 softmax = vector 主 + MTE1 辅助 + S 辅助。
• 先不允许：同一 tileop 同时混 cube 主算 + vector 主算。
• 需补充的 MTE 归类：classifyTileOpByPipe 现把 MTE2/MTE3 归 default(未知)，cube helper 含 mte_l1_l0a(MTE2) 会让主域推导失败。MVP 边界需明确把 MTE1/2/3 归"辅助 pipe"（不参与主域判定，不触发混合段报错），否则 cube+MTE 的 tileop 推导会失败。

这条边界让 softmax 完全落在内，不破现有单主 pipe 假设；同时为后续放开 cube+vector 混算留扩展点（届时再改那三处单 pipe 假设）。

复用是 custom kernel 刚需；B复用现有 call 穿透机制，升级 role→pipe 摘要即可消费多 pipe，是渐进演进而非重做，工程量与风险可控。arg_effects/has_sync 让 caller 层 sync 从保守变精确，弥补"不进 body"的精度损失；更优 sync 可后置内联 opt pass。

[Zhendong404]

1. 希望subkernel也能支持区分输入输出，可能有利于pass优化
2. pto.ptodsl.subkernel_helper = "tileop"这个有点怪，统一用pto.tileop.xxx?
3. compute_domain感觉直接复用已有的kernel_kind比较好，不用再引入新概念
4. has_sync这个我认为没必要，除非能说清楚insert sync pass拿到这个信息能做什么，否则我们的假设就是subkernel内部自己负责同步