TypeConverter 是 DialectConversionPass 正常运行的前提，负责方言间类型映射；缺失时 convertTypes 和 applyPartialConversion 会静默失败或崩溃，因框架无法识别如 !tt.ptr 到 memref 的转换。
TypeConverter 是 MLIR 方言转换中类型映射的“翻译官”，不是可选配件，而是 DialectConversionPass 能跑起来的前提。 没它，convertTypes、applyPartialConversion 都会静默失败或崩溃——因为转换框架根本不知道 !tt.ptr<f32></f32> 该变成 memref<?xf32> 还是 llvm.ptr<f32></f32>。
为什么 addConversion 顺序会影响转换结果
MLIR 的 TypeConverter 匹配是**从上到下第一个成功者胜出**，不回溯。如果你把泛化规则（比如 identity fallback）放在前面，特化规则（比如 triton::PointerType → memref）就永远没机会执行。
- 错误写法：
addConversion([](Type t) { return t; });放第一行 → 所有类型都被原样透传，后续规则全被跳过 - 正确顺序：先注册明确的特化转换（指针、张量），最后用 identity 保底处理基础类型（
i32、f32等） - 注意：
convertType在递归调用时也会走同一套链，所以指针元素类型（如!tt.ptr>）必须能被已注册的规则覆盖，否则报failed to convert type
怎么写一个安全的 Triton 指针到 memref 的转换
直接把 !tt.ptr<t></t> 映射成 memref<?xT> 看似简单，但实际要防三类坑：
- 不能硬编码维度数：Triton 允许任意偏移算术（
ptr + 3），多维memref无法表达这种线性地址空间 → 必须用动态维度memref<?xf32> - 元素类型必须递归转换：如果
T是!tt.ptr<i32></i32>，那最终目标得是memref<?xmemref <?xi32>>，不是memref<?x !tt.ptr<i32>> - 空指针或未定义行为不处理：TypeConverter 只管类型，不管值语义；运行时越界访问仍由后端（如 RISC-V 地址检查）兜底
示例片段：
addConversion([&](triton::PointerType type) -> Type {
Type eltType = type.getPointeeType();
Type convertedElt = convertType(eltType); // ← 关键：递归调用
return MemRefType::get({ShapedType::kDynamic}, convertedElt);
});
tensor 到 vector 转换时的尺寸对齐陷阱
把 tensor 直接转成 vector 很自然，但遇到 tensor 就得小心了：
- RISC-V RVV 要求向量长度是 vlenb 的整数倍，而编译期不一定知道 vlenb → 实际常转成
vector并加 mask - MLIR
vectordialect 不支持“部分填充”语义，所以tensor若强制转vector，后端 lowering 可能失败 - 更稳妥做法：在 TypeConverter 中只处理能整除的尺寸（
isPowerOf2(size)），其余抛错或降级为标量循环 —— 把决策点留在类型转换层，而非让下游 pass 去猜
真正难的不是写几个 addConversion，而是想清楚哪些类型差异必须在 TypeConverter 层抹平（比如指针→memref），哪些该留到 Operation ConversionPattern 里用 rewriter.create<...> 补足（比如如何生成 load/store 序列）。混淆这两层，调试时会卡在“类型对了但 IR 合法性校验过不去”的死循环里。
