前端算子目录（deepx·op）+ 编译器 pass：读 /lib 后端绑定 + 复合算子融合版本化

[miaobyte]

背景

延续 #1（deepx-cpu-compute 重建为 kvlang main-runtime + CPU tensor myrwircaps）。现状：后端算子以 deepx/<author>·<op> 注册为 def rwir（myrwircaps_find 精确串匹配，无优先级/无 fallback/无版本），.kv 里直接写死具体后端，无前端抽象层。

kvlang 核心契约见 array2d/kvlang#273（spec 卷 06-编译器语义）。本 issue 实现 deepx 侧的前端算子目录与编译器 pass。

范围

1. 前端算子（抽象）目录 —— deepx·<op>

• 定义厂商中立的前端算子 schema：/lib/deepx·<op>，schema-only def rwir + abstract 标记，只承诺签名与语义，无实现、无 author。首批对齐已有/在建后端：argmax、matmul、softmax（复合）等。
• argmax schema（依 deepx-design op-list 既有约定）：argmax(tensor<any>:A, var<int32>:axis, var<bool>:keepdims) -> (tensor<int64|int32>:B)。属性（axis/keepdims）作普通位置参数（var/vector），非独立 attribute 字段——与 deepx reduce 族一致。
• author ≈ PyTorch DispatchKey：miaobyte/cblas/cublas/default_（见 deepx-core tensorfunc/authors.hpp）。前端 deepx·op 无 author，后端 deepx/<author>·op 有。

2. 编译器 pass —— 读 /lib，生成新函数

• 后端绑定：扫 /lib 全部调用点，对抽象算子 deepx·<op>，枚举已注册 deepx/*·<op> 后端，按策略选一，就地改写调用点 opcode 为 deepx/<author>·<op>。
• 选择策略：① 源码显式 author（deepx/cblas·matmul）保留 → ② 默认 author 表（authormap 式：matmul→cblas、argmax→miaobyte，可配置）→ ③ 唯一可用者 → ④ 皆无则诊断「op 无已注册后端」。
• 复合算子分解/融合：deepx·softmax（= exp/sum/broadcast/div 组合的 rwfunc）→ 融合成单条自解释 rwir，登记为版本 softmax.1（写 /lib/deepx·softmax.1 + 基键 maxversion 标记）。runtime 侧高版本优先由 kvlang#273 兑现。
• 定位：编译器介于 layout 之后、runtime 之前，运行在「已 layout 且各计算 runtime 已注册 myrwircaps」的 kvspace /lib 树上（复用 core 骨架，见 kvlang#166）。产物仍是合法 /lib 树。

3. 对照 PyTorch（参照，不照搬）

• 后端绑定 ≈ TorchInductor lowering 表（编译期静态绑定），非 c10::Dispatcher 运行期 device 派发。
• deepx·op/deepx/author·op ≈ TORCH_LIBRARY m.def / TORCH_LIBRARY_IMPL(deepx,<author>,m).impl。
• 复合算子 ≈ CompositeImplicitAutograd + torch/_decomp；融合 ≈ Inductor Scheduler → 单 kernel；版本择优 ≈ autotune 缓存最优。

验收

• 用户锚例：deepx·argmax(v0, axis0, false) -> vmax 编译为 deepx/miaobyte·argmax(...) 并正确执行。
• softmax 编译前后输出逐字节一致，编译后走 softmax.1。

关联

array2d/kvlang#273（核心契约 + spec 卷 06）、#1、kvlang#166 #189 #202。

[miaobyte]

与 deepx-cuda-kernelcompiler（op-gpu）的分工 —— 编译器 pass 精化

op-gpu 是 GPU 侧的叶子 kernel 编译器：把一组 deepx·{rwir/rwfunc} codegen 成单次 GPU kernel 调用。通读它后，本 issue 的「编译器 pass」应据此对齐分工：

• 本 pass = 编排器：读 /lib、后端绑定、识别可融合 rwir 组、调下游 kernel 编译器、拿回 .so+meta 后回写（注册融合产物为 /lib/<opcode> def rwir + myrwircaps、改写调用点、登记版本 .N）。op-gpu 实现里没有回写（只返回 CompileResult 对拍），回写这一步正是本 pass 要补的。
• 下游 kernel 编译器（op-gpu）= 纯函数式服务：输入 op序列 + shape + dtype（op-gpu 文档定义为一段 JSON {func,pattern,ops,inputs[shape,dtype],outputs,accum_dtype}），输出 .so + meta，不回写 kvspace、不感知调度。

精化点：

1. 融合匹配用子序列/滑窗，非 op-gpu 现在的整段 opcode 元组精确匹配（其 FUSION_DB 手工枚举 30 case、不可扩展）。
2. 切分硬边界：融合组内重算子（GEMM/conv）计数 ≥ 阈值（典型 2）即拆多 kernel（op-gpu fusion.py 的 multi_kernel 判据）。
3. 四态融合状态表（可融单核 / 缺模板 / 须拆多核 / 不可融），「规则即数据」。
4. CPU 侧同理需要一个叶子 kernel 编译器（或直接映射到 deepx-cpu-compute 的 SIMD/BLAS 融合实现）；GPU 侧复用 op-gpu。多后端 deepx/<author>·op 统一到「同一 rwir + 同一裸指针调用约定」的抽象工厂，author 只是选择维度，便于对拍择优（op-gpu 已用 speedup 对比做雏形）。
5. 产物缓存键 (基op, 版本.N, shape-hash, dtype, author)——语义版本号与 shape 特化正交，见 3-compiler: kvlang 编译器 —— 前端算子表示 + 后端绑定 + 算子版本化（核心契约与 runtime 高版本优先） kvlang#273 评论。

关联：array2d/kvlang#273、array2d/deepx-cuda-kernelcompiler。