[EPIC] 3-compiler: kvlang 编译器 —— 前端算子表示 + 后端绑定 + 算子版本化（核心契约与 runtime 高版本优先）

[miaobyte]

背景

引擎 deepx-cpu-compute（#1，main-runtime + CPU tensor myrwircaps）已能把后端算子按 deepx/<author>·<op>（如 deepx/miaobyte·argmax、deepx/cblas·matmul）注册为 def rwir。但 kvlang 尚缺 前端算子表示 与把前端代码对接引擎 rwir 的 编译器。

目标（用户原述）：deepx 表示代码

v0:[]float64 = [1.0, 3.0, 2.0, 7.0, 4.0]
axis0:[]int64 = [0]
deepx·argmax(v0, axis0, false) -> vmax

编译为执行代码

v0:[]float64 = [1.0, 3.0, 2.0, 7.0, 4.0]
axis0:[]int64 = [0]
deepx/miaobyte·argmax(v0, axis0, false) -> vmax

编译器与 layout 的区别：编译器直接读 /lib，检查当前注册的所有后端算子实现后，再生成新函数。复合算子 rwfunc softmax → 融合版 rwfunc softmax.1（类 .so.1 版本后缀），runtime 调 softmax 时优先高版本。

三阶段定位

layout（o0，检查+布局+降级，不优化）→ 编译器（读 /lib 优化）→ runtime（纯解释）。spec 卷 00 早已用「扩展编译器」一词并与 layout(o0) 对置（00-导言/01-范围与一致性.kv:18），本工作即定义它。编译器不属语言核心 runtime，是计算引擎（deepx-cpu-compute/deepx-gpu-compute）的组成（延续 #189、执行模型.kv:7）。与 #202「layout 不是编译器」正交互补。

本 issue（kvlang 核心侧）范围 —— 只做契约，编译器本体在 deepx-cpu-compute

• spec 卷 06-编译器语义（已起草，待评审/落库）：01-编译器定位、02-前端算子与后端算子、03-算子版本化与高版本优先，并在 00-导言/01 范围登记卷 06。
• 前端算子（抽象）表示：/lib/<域>·<op>（deepx·argmax），schema-only def rwir + abstract 标记；无 myrwircaps 兑现方。runtime 遇未编译的抽象算子调用 → 明确诊断「抽象算子未绑定后端，需先经编译器」（不静默 handoff / 不回退 NameError）。
• runtime 高版本优先解析（2-runtime）：handle_call 构出 func_key=/lib/<pkg>·<name> 后、读 [0,0] 前，读基键版本标记，有则重定向到 /lib/<pkg>·<name>.<maxN>，无则用基键（向后兼容）。对 caller 透明，按基名缓存冻结。挂钩点 runtime/src/kvcpu.c handle_call（构 func_key 之后，约 kvcpu.c:340-348）。
• 锚例：tutorial/16-compiler/backend_bind.kv、op_version.kv（三后端逐字节一致）。

关键设计裁决

1. 版本记法用 .<N> 而非 ·<N>（用户裁定）：· 是包/成员分隔符，rfind_sep 会把 softmax·1 误拆为 pkg=softmax,name=1；. 不是分隔符（词法上并入标识符、handle_call 不据它拆 pkg/name），故 softmax.1 整体即 name，无歧义，且与既有 .src 后缀约定一致。版本键 /lib/<pkg>·<name>.<N>。
2. 后端选择策略：显式 author 保留 → 默认 author 表（authormap 式，matmul→cblas/argmax→miaobyte）→ 唯一可用 → 皆无则诊断。策略本体在计算引擎侧。
3. 后端绑定 vs 版本化正交：绑定改调用点 opcode（前端→后端）；版本化改被调实现选择（基→高版本）。

对照 PyTorch（勘察结论）

编译期读 /lib 静态绑定后端 ≈ TorchInductor lowering（非 c10::Dispatcher 运行期 device 派发）；前端算子 ≈ TORCH_LIBRARY m.def，后端算子 ≈ TORCH_LIBRARY_IMPL(域,author,m)；复合算子 ≈ CompositeImplicitAutograd+torch/_decomp；融合 ≈ Inductor Scheduler；版本择优 ≈ autotune 缓存最优（kvlang 把它显式化为静态版本号）。

关联

deepx-cpu-compute 侧实现见 array2d/deepx-cpu-compute#2（前端算子目录 + 编译器 pass）。#202 #189 #166 #1。

[miaobyte]

通读 deepx-cuda-kernelcompiler（op-gpu）后的设计精化

op-gpu 负责把多个 deepx·{rwir/rwfunc} 进一步融合成一次 GPU kernel 调用（=一条 rwir）。通读其实现（Python 原型，kvfunc.py/fusion.py/kernel*.py）与设计文档（doc/kernel-compiler-analysis.md、kvlang-to-tilelang-interface.md）后，已把以下精化写进 spec 卷 06：

1. 融合分两层，职责切开（→ spec 01-编译器定位 新增「融合的层级」节）：

   • kvlang 编译器（编排器）：读 /lib、后端绑定、复合分解、识别可融合 rwir 组、回写（注册 /lib/<opcode> def rwir + myrwircaps、改写调用点、登记版本）。
   • kernel 编译器（叶子 codegen，op-gpu）：吃 op序列+shape+dtype、吐 .so+meta 的纯函数式服务，不回写、不感知调度。回写归编排器（对齐 op-gpu 文档 compile.Fuse(*ast.File)→*ast.File 的分工）。
   • 对照 PyTorch：编排器 ≈ Inductor lowering+Scheduler；kernel 编译器 ≈ Inductor codegen 后端（Triton/C++）。

2. 融合匹配须子序列/滑窗，非整段 opcode 元组精确匹配。op-gpu 现用 FUSION_DB 整段元组查表 + 手工枚举 30 case，不可扩展。切分硬边界：重算子（GEMM/conv）计数超阈值（典型 ≥2 GEMM）即拆多 kernel。规则宜「规则即数据」表 + 四态（可融单核/缺模板/须拆多核/不可融）。

3. 版本号 ⊥ shape 特化（→ spec 03 新增「版本号与 shape 特化正交」节）：runtime 高版本解析只认语义版本 .<N>；shape 特化多产物按 shape-hash 缓存归计算引擎/kernel 编译器。完整实现选择键 (基op, 版本.N, shape-hash, dtype, author/backend)。别把 shape 特化冒充版本号。

4. AOT 必须是显式里程碑：op-gpu 文档画了完整 AOT→.so→dlopen（fn(ptr...,stream)） 管线，代码却只落一个 JIT 的 linear kernel、硬编码 shape、零缓存零回写。C++ 运行时零 Python 依赖这条约束决定必须走 AOT 而非 tilelang.jit，须早期钉死、独立验收。

（op-gpu 自身补齐 AOT/.so/dlopen/shape-hash 缓存/回写，宜另开 deepx-cuda-kernelcompiler issue。）