one-shot-bufferize是官方推荐的tensor→memref转换方式，因其能完整分析数据流、别名与buffer复用，自动处理alloc/dealloc和in-place更新；手动转换易导致内存越界或重复释放。
直接用 one-shot-bufferize Pass，这是当前 MLIR 官方推荐的 tensor → memref 转换方式。旧的方言级 bufferization（如 linalg-bufferize）已基本弃用，除非你卡在特定历史版本或函数边界缓冲区需求中。
为什么必须用 one-shot-bufferize 而不是手动写转换？
因为 tensor 是值语义、不可变、无内存布局；memref 是引用语义、可变、带维度/步长/对齐信息。二者语义鸿沟大，不能靠简单类型替换完成——需要分析数据流、别名、写入顺序、buffer 复用机会。MLIR 的 one-shot-bufferize 会做完整的 buffer analysis，自动插入 alloc/dealloc、处理 in-place 更新、识别 anchor operands（比如 linalg.generic 的 outs），而手写 dialect conversion 很容易漏掉 aliasing 场景，导致内存越界或重复释放。
常见错误现象包括：
-
error: 'memref.alloc' op operand #0 must be signless integer, but got 'index'—— 没提前运行canonicalize或affine-loop-normalize，index 类型未被规范化 - 生成的 memref 维度全为
?x?xf32，无法降级到 LLVM —— 缺少 shape refinement pass，比如resolve-shape-functions或buffer-deallocation前未跑rank-reduction - buffer 内容错乱或未初始化 —— tensor 操作有隐式 broadcast 或 fill 行为，
one-shot-bufferize默认不推导初始值，需显式加--bufferize-byte-allocation或用tensor.generate提前构造
one-shot-bufferize 的关键参数和使用场景
它不是一个“开箱即用”的黑盒，不同场景要调参数：
- 默认模式（最常用）：
--pass-pipeline="builtin.module(one-shot-bufferize{copy-before-write=true})"。适合大多数 linalg/tensor 流水线，自动插入 copy 防止写冲突 - 追求 zero-copy（如 GPU kernel 输入输出复用）：
copy-before-write=false，但要求 IR 中所有 tensor operand 都有明确的 buffer anchor（如outs或tensor.extract_slice的 base） - 含动态 shape 的模型（如 PyTorch 动态 batch）：
allow-dynamic-allocs=true，否则遇到tensor<?x4xf32>会直接失败 - 需要控制 alloc 插入位置（比如想把 alloc 提升到函数开头）：
bufferize-function-boundaries=true，配合func.func的bufferizable-op-interface实现
注意：one-shot-bufferize 不处理 memref → LLVM pointer 的转换，那是 finalize-memref-to-llvm 的事。它只管 tensor → memref 这一层。
tensor → memref 后，怎么确认结果正确？
最容易被忽略的是 buffer lifetime 和 aliasing 关系。建议三步验证：
- 用
--print-ir-after=one-shot-bufferize看 IR：检查是否所有tensor.op 都消失了，是否每个memref.alloc都有对应memref.dealloc（除非用了no-dealloc） - 加
--verify-each运行 pipeline：它会在每个 pass 后校验 IR 合法性，能快速暴露 buffer analysis 错误（比如同一 buffer 被两个不相交的 write 同时 claim） - 人工扫一遍
memref.subview/memref.cast：这些 op 容易引入 dangling reference，尤其当原 tensor 有 slice chain 时，one-shot-bufferize可能生成嵌套 subview，LLVM backend 不一定支持
真正难的不是“怎么转”，而是“转完之后 buffer 图是否符合你的硬件约束”——比如 RISC-V vector backend 要求 memref stride 对齐到 vlen，这得靠后续的 vector.contract + layout-aware allocation，而不是 bufferization 本身解决。
