[RFC] Self-consistent IR TensorType layout representation

[YunjiQin]

Summary

PyPTO IR's TensorType.tensor_view_ field has two conflicting semantics for the layout (DN) tag, depending on whether stride is empty. Codegen disambiguates via tensor_view_->stride.empty() — same TensorType structure, different meanings of shape_. This RFC proposes a self-consistent canonical form where shape_ is always logical, stride is per-logical-dim element step, and layout is a derivable / asserted constraint tag.

Motivation

Two conflicting paths producing the same IR shape:

Semantic A — matmul B^T path: User writes pl.Tensor[[N, K], pl.FP32]; ResolveTransposeLayout adds DN tag with empty stride. shape_ is the source-tensor shape; codegen swaps trailing two dims when emitting pto.make_tensor_view (get_shape_source_idx in pto_codegen.cpp). tile.load similarly swaps offsets/sizes via dn_swap.

Reference: tests/st/runtime/test_matmul.py::TestMatmulOperations::test_matmul_btranspose, output dir build_output/matmul_btranspose_32x64x32_*.

Semantic B — tensor.transpose path (post commit c6b6027): transpose([8, 16] ND) produces Tensor[[16, 8], DN, stride=[1, 16]]. shape_ is the logical post-transpose shape; stride explicitly describes col-major access. Codegen uses (shape, stride) as-is via has_explicit_stride.

Reference: tests/st/runtime/test_trans.py, output dir build_output/TransposeSliceRepro_*.

Root cause: A single TensorType structure carries two incompatible interpretations of shape_. c6b6027 patched tensor.transpose with explicit stride to coexist with the legacy DN-swap convention, but the underlying ambiguity remains. Any new pass / op touching DN tensors must navigate this ambiguity.

Fixing this enables:

• Mechanical codegen (no dn_swap, no has_explicit_stride branching).
• Composability between tensor.transpose, slice, and matmul B^T paths without special cases.
• Clear contract for orch / IR / Incore / .pto boundaries.

Related symptoms: #1213 (matmul b_trans=True wrong results), #1230 (ND→ColMajor Vec tile rejection).

Design

A full design proposal is published in the first comment below.

1. Background and conflict examples.
2. Canonical TensorType invariants (shape_ = logical; stride per logical dim; layout consistent with stride).
3. Layout family table (ND-packed / ND-strided / DN-packed / DN-strided / NZ).
4. BuildLogicalStridesFromLayout(shape, layout) formula.
5. "Codegen entry must have explicit stride" contract via new MaterializeTensorStrides pass + VerifyTensorViewCanonical.
6. Five frontend examples covering ND / explicit DN / matmul B^T / tensor.transpose / DN-slice.
7. Orch ↔ IR ↔ Incore ↔ .pto field-by-field mapping table.
8. New virtual op tensor.as_layout for orch↔Incore type bridging.

Open Questions

1. Should tensor.as_layout be exposed in the user-facing Python DSL, or kept as an internal IR-only op produced by LowerTransposeLoadParamLayout?
2. For symbolic strides where stride[-1] >= shape[-2] cannot be statically verified, do we accept the structural equality stride[-2] == 1 only and skip the >= check, or require an explicit constraint annotation?
3. Inside convert_tensor_to_tile_ops_pass.cpp, the layout kwarg propagated to tensor.create() currently includes the legacy DN-swap convention — what changes here once IR is canonical?

Git Commit ID

1810c34

[YunjiQin]

IR Tensor Layout 自洽表示方案

本文档定义 PyPTO IR 上 TensorType.tensor_view_ 中 (shape, stride, layout) 三元组的统一语义，
解决 TensorLayout 双重含义问题。

1. 背景与目标

1.1 现状：TensorLayout 双重语义

同一个 TensorType 结构（shape, stride, layout）当前被赋予两种不一致的含义：

Semantic A — matmul B^T 路径：用户写 pl.Tensor[[N, K], pl.FP32]（无 layout 标记），
ResolveTransposeLayout pass 检测到 tile.load(transpose=True) 后追加 DN 标签：

b: TensorType(shape=[N, K], view=TensorView(stride=[], layout=DN))

此时 shape_ 仍是源张量 shape；DN 是「让 codegen 在 emit pto.make_tensor_view 时把后两维 swap 成 [K, N]」的标记。
Swap 实际发生在 EmitMakeTensorViews 内（pto_codegen.cpp 的 get_shape_source_idx），
tile.load 通过 dn_swap 把 offsets/sizes 也 swap 一次。

Semantic B — tensor.transpose 路径（c6b60273 之后）：

xt = transpose(x: [8, 16] ND)
xt: TensorType(shape=[16, 8], view=TensorView(stride=[1, 16], layout=DN))

此时 shape_ 是逻辑后视图 shape；stride 显式描述列主序访问。
Codegen 通过 has_explicit_stride 跳过 swap，直接转录。

根因：codegen 用 tensor_view_->stride.empty() 在两条路径之间分流。shape_ 在两条路径中的所指（storage vs. logical）不同；c6b60273 让二者能共存而非真正解决冲突。

1.2 目标

• IR 上 TensorType 单一语义；任何 pass / codegen 看到 (shape, stride, layout) 都能机械地解释。
• Codegen 完全机械化：不再做隐式 swap，不再推算 stride。
• Runtime / Orch、IR、Incore、.pto 四层语义统一。

---

2. 新设计规则

2.1 Canonical TensorType 不变量

字段	含义
TensorType.shape_	逻辑 shape，consumer（passes / ops / codegen）索引时看到的维度
TensorView.stride[i]	第 i 个逻辑维递增 1 时的元素步长（element 数，可符号）
TensorView.layout	stride 模式标签，与 stride 一致；不可独立变化

地址计算：任意逻辑索引 (i_0, ..., i_{n-1}) 对应物理偏移

offset = Σ_{k=0..n-1}  i_k · stride[k]

不存在「下游再 swap」的隐含约定。

契约：codegen 阶段看到的 TensorType 必有显式 stride（见 §2.4）。

2.2 Layout 家族

每个 layout 定义两种合法形态：packed canonical（紧致存储，由 layout + shape 唯一决定 stride）和 strided 家族（slice / sub-view 后仍属于该 layout，stride 是从父继承而来的「合法子集」）。

Layout	Packed canonical	Strided 家族	适用	典型来源
ND	stride[-1]=1，stride[k]=stride[k+1]·shape[k+1]（行主序紧致）	stride[-1]=1；前导步长可大于紧致值（描述行主序父 buffer 的子视图）	tensor / tile	默认连续行主序张量 / OptimizeOrchTensors 处理 slice/assemble 派生的 InCore 参数
DN	stride[-2]=1，stride[-1]=shape[-2]，前导维按行主序展开	stride[-2]=1；stride[-1] ≥ shape[-2]，前导步长可任意	tensor (Vec)、tile (NoneBox + ColMajor)	用户显式 pl.Tensor[[K, N], pl.DN] / tensor.transpose 输出 / DN 父张量上的 slice
NZ / ZN / NN / ZZ	分形布局，stride 不直接表达，由 fractal + BLayout/SLayout 共同定义	不允许任意 stride（破坏分形结构）	tile-only	tile.load 输出到 L1 的矩阵乘左/右操作数等

stride=[] 的含义：

• 解析期允许作为简短输入形式，表示「采用该 layout 的 packed canonical strides」。
• MaterializeTensorStrides pass 在 codegen 之前统一展开为显式 stride。
• Verifier 在 codegen 入口强制 !stride.empty() && stride.size() == shape.size()。

2.3 BuildLogicalStridesFromLayout(shape, layout) 公式

给定 logical shape [S_0, ..., S_{n-1}]，packed canonical strides 计算如下：

ND：

stride[n-1] = 1
stride[k]   = stride[k+1] · S_{k+1}        (k = n-2 down to 0)

DN（n ≥ 2）：

stride[n-2] = 1
stride[n-1] = S_{n-2}
stride[n-3] = S_{n-2} · S_{n-1}
stride[k]   = stride[k+1] · S_{k+1}        (k = n-4 down to 0；前导维按行主序展开)

NZ / ZN / NN / ZZ：函数 CHECK-fail。这些 layout 仅在 tile 使用，且 stride 无法描述 fractal。

实现层面：所有乘法走 MakeIndexMul（已在 transform.cpp 内），ConstInt 链折叠、symbolic 维保留为 Mul 表达式。

2.4 「Codegen 入口必有显式 stride」契约

解析期        ──┐
                ├─►  允许 stride=[]（简短输入形式）
中间 pass     ──┘
                ▼
[MaterializeTensorStrides pass]
                ▼
解析期/中间 pass ──┐
                  ├─►  必有显式 stride
codegen          ──┘

约束：

• 解析期 / 早期中间 pass：允许 tensor_view_->stride.empty()，由 layout 隐含 packed 形式。
• MaterializeTensorStrides pass：遍历 IR，把所有 stride.empty() 处展开为 BuildLogicalStridesFromLayout(shape, layout)。
• MaterializeTensorStrides 之后：VerifyTensorViewCanonical 强制 stride.size() == shape.size() && !stride.empty()。
• Codegen EmitMakeTensorViews：直接读 tensor_view_->stride。缺失即 INTERNAL_CHECK 报错（违反前置 pass 契约）。

---

3. 前端写法示例

每个示例给出：用户写法 → 解析后 IR → MaterializeTensorStrides 之后的 IR → .pto 输出片段。

3.1 普通 ND

a: pl.Tensor[[M, N], pl.FP32]

• 解析后：TensorType(shape=[M, N], view=None)
• 物化后：TensorType(shape=[M, N], view=TensorView(stride=[N, 1], layout=ND))
• .pto：pto.make_tensor_view ... [..., M, N], [..., N, 1] {layout = #pto.layout<nd>}

3.2 显式 DN（逻辑 shape 写法 —— 破坏性变更入口）

b: pl.Tensor[[K, N], pl.FP32, pl.DN]

• 解析后：TensorType(shape=[K, N], view=TensorView(stride=[], layout=DN))
• 物化后：TensorType(shape=[K, N], view=TensorView(stride=[1, K], layout=DN))
• .pto：pto.make_tensor_view ... [..., K, N], [..., 1, K] {layout = #pto.layout<dn>}

⚠️ 注意：此处 [K, N] 是逻辑后视图 shape。runtime 实际传入的 torch tensor 形状应是 [N, K] 行主序（参见 §4 中 matmul B^T 的 memory 解析）。

3.3 matmul B^T（保留 transpose=True 便利接口）

b: pl.Tensor[[N, K], pl.FP32]                 # 源张量 shape，与今日相同
pl.load(b, offsets=[0, 0], shapes=[N, K],
        target_memory=pl.MemorySpace.Mat, transpose=True)

• 解析后：b: TensorType(shape=[N, K], view=None)
• LowerTransposeLoadParamLayout pass 之后（同时改写 InCore 函数签名 + 所有 call site）：
  • InCore 侧：参数类型 b: TensorType(shape=[K, N], view=TensorView(stride=[1, K], layout=DN))；body 内 pl.load 改写为 pl.load(b, offsets=[0, 0], shapes=[K, N], target_memory=...)，transpose=True 标志被消化，offsets / shapes 后两维互换以匹配新 shape 坐标系。
  • Orch 侧：原 call site 传入的实参类型仍是 [N, K], ND（runtime 传入的 torch tensor 形状不变）。pass 在 call site 插入虚 op 桥接：

    %b_as_dn = tensor.as_layout(%b_orch, shape=[K, N], layout=DN)
                                    : Tensor[[N,K], ND] -> Tensor[[K,N], DN]
    incore_func(%b_as_dn, ...)
    

• 物化后：与 §3.2 相同
• .pto：与 §3.2 相同；tensor.as_layout 是纯元数据操作，codegen 不发射任何指令（仅在生成 make_tensor_view 时使用变换后的 (shape, stride, layout)）。

用户代码无需修改：依赖 pass 自动转 canonical 并桥接。

虚 op tensor.as_layout 规范

• 签名：tensor.as_layout(src: Tensor, shape: tuple[int...], layout: TensorLayout) -> Tensor
• 语义：纯元数据 reinterpret；指向同一片物理内存，仅改变 IR 上的 (shape, layout, stride) 描述。
• 合法性约束：
  • src 与输出必须覆盖同一组物理 element（element 总数相等，且每个逻辑索引在两侧都有一一对应的物理偏移）。
  • 对 matmul B^T 的 [N, K] ND → [K, N] DN 桥接：runtime row-major [N, K] 与 IR [K, N] DN 描述同一片内存（mem[n, k] ≡ DN 视图下的 view[k, n]，物理偏移都是 n·K + k = k·1 + n·K）。✓
  • 校验由 verifier 完成（基于 stride 公式比对两侧 offset map）。
• codegen：不发射任何 PTOAS 指令；下游 make_tensor_view 直接使用输出端的 (shape, stride, layout)。
• 优化：相邻的 as_layout 链 / as_layout(as_layout(x)) 可由 Simplify 折叠或消除。
• 位置：op 定义放在 tensor_ops 类别下，与 tensor.transpose / tensor.slice 同级。

3.4 pl.tensor.transpose 结果（c6b60273 已 canonical）

x: pl.Tensor[[8, 16], pl.FP32]
xt = pl.transpose(x, 0, 1)                    # xt 类型由 op 推导

• xt 类型推导：TensorType(shape=[16, 8], view=TensorView(stride=[1, 16], layout=DN))
• 物化后：与上同（已是显式 stride）
• .pto：pto.make_tensor_view ... [..., 16, 8], [..., 1, 16] {layout = #pto.layout<dn>}

3.5 DN 张量上做 slice（strided-DN 家族）

b: pl.Tensor[[K, N], pl.FP32, pl.DN]                            # 父：DN-packed
b_sub = pl.slice(b, [K_sub, N_sub], [k0, n0])                   # 子：strided-DN

• b 物化后：TensorType(shape=[K, N], view=(stride=[1, K], layout=DN))
• b_sub 类型推导：TensorType(shape=[K_sub, N_sub], view=(stride=[1, K], layout=DN))
  • stride 继承自父，落入 strided-DN 家族
  • stride[-2]=1 仍成立 ✓；stride[-1]=K ≥ shape[-2]=K_sub ✓
• .pto：pto.make_tensor_view ... [..., K_sub, N_sub], [..., 1, K] {layout = #pto.layout<dn>}

---

4. Orch / IR / Incore / .pto 对照表

下表以 matmul B^T 场景 为例，N=8、K=4，描述同一片 32 元素物理内存在四层之间的字段对照。

物理内存：runtime 传入 Tensor(shape=[8, 4])（即 N=8 行 × K=4 列），row-major 存储。
Element mem[n, k] 在物理偏移 n·4 + k，n ∈ [0, 8)，k ∈ [0, 4)。

层	描述对象	shape	stride（element）	layout 标签	view[i, j] 物理偏移	对应 mem 元素
Runtime / Orch	Tensor(shape=[8, 4])	[8, 4]	隐式 [4, 1]	无（永远行主序）	i·4 + j	mem[i, j]
IR ND-packed（与 runtime 等价描述）	默认或显式 ND	[8, 4]	[4, 1]	ND	i·4 + j	mem[i, j]
IR DN-packed（matmul B^T canonical 视图）	用户写 [K, N], pl.DN，即 [4, 8] DN	[4, 8]	[1, 4]	DN	i + j·4	mem[j, i]（逻辑转置）
Incore 视角	同一参数被传入 InCore 函数后类型不变；tile.load 从该 view 取 tile	[4, 8]	[1, 4]	DN	同上	同上；tile 自身的 BLayout/SLayout 由 ResolveBackendOpLayouts 决定
.pto MLIR	pto.make_tensor_view（codegen 一一映射）	[..., 4, 8]	[..., 1, 4]	#pto.layout<dn>	同上	同上

4.1 关键澄清：DN-packed vs. 行主序父 buffer 的 transpose 视图

两者在「描述同一片 row-major 物理内存」时是同一种 IR 表示：

来源	shape	stride	layout
[K, N] DN-packed 公式实例化（Tensor[[K, N], pl.DN]）	[K, N]	[1, K]（由公式 stride[-2]=1, stride[-1]=K 得出）	DN
transpose([N, K] ND) 的输出	[K, N]	[1, K]（来自父 stride [K, 1] 在 (axis0, axis1) 上的交换）	DN

→ 两条路径产出完全相同的 canonical TensorType，因此 codegen 不需要再分支区分「来源」。

4.2 重要澄清：runtime 始终行主序，IR DN 只是「视图相」

Tensor 地址空间由 runtime 管理；所有物理 buffer 都是行主序字节排布——核内（InCore）不能创建 tensor。tensor.create(layout=DN, ...) 只能出现在 orch 层，落到 runtime 时仍是按 shape 行主序分配的字节缓冲。

因此，IR 上的 DN（无论是 packed 还是 strided 家族）永远是对某段 row-major 物理内存的「转置视图」，并不存在真正的「物理列主序存储」。直观对照：

# Orch 层
b_dn = pl.tensor.create(shape=[K, N], dtype=pl.FP32, layout=pl.DN)
# IR：TensorType(shape=[K, N], view=(stride=[1, K], layout=DN))
# Runtime：分配长度 K·N 个 element 的 buffer，按 [N, K] row-major 解释
#         （因为 DN-packed 公式得出的 stride [1, K] 恰好等价于 row-major [N, K] 的 stride [K, 1] 的转置视图）

读 element：b_dn[i, j] 在物理偏移 i + j·K，等同于 row-major [N, K] buffer 中的 [j, i]。

→ 这就是 §4.1 的另一种说法：DN-packed 公式产出的 stride，与「row-major 父 buffer 的 transpose 视图」必然产出同一组 stride。两者在 PyPTO 中是同一种 IR 表示，对应同一片 runtime 物理内存。

这一性质让 tensor.as_layout（§3.3）的合法性总是成立：把 orch 侧 [N, K] ND 重解释为 [K, N] DN 永远是合法的 metadata 操作，不需要数据搬运。

---

5. 各层语义边界小结

• Runtime / Orch：tensor 永远行主序、无 layout 概念；stride 隐式按 shape 行主序展开。
• IR：单一 canonical 形式 (shape, stride, layout)；shape 永远 logical；layout 是 stride 模式标签，与 stride 一致。
• Incore：参数 / tensor.create 输出 / tile.load 源都使用同一 canonical 形式。tile 自身的 layout（BLayout / SLayout / fractal）是另一回事，由 ResolveBackendOpLayouts 等 pass 处理。
• .pto MLIR：codegen 把 (shape, stride, layout) 字段一一映射到 pto.make_tensor_view 属性，无任何隐式 swap。

---

6. 实现路线（forward-looking outline）

本设计文档不附带代码改动；落地分多个 PR 推进，每步配 verifier 兜底防回归。

1. 新增 tensor_view_semantics.h：提供 BuildLogicalStridesFromLayout / IsCanonicalView / CanonicalizeView / DeriveLayoutFromStrides 等辅助函数。
2. 新增 MaterializeTensorStrides pass：在 codegen 之前展开 stride=[] 为 packed canonical。
3. 新增 VerifyTensorViewCanonical verifier：注册 IRProperty kTensorViewCanonical，在 pass pipeline 关键节点强制不变量。
4. 重命名 ResolveTransposeLayout → LowerTransposeLoadParamLayout：由「仅打 DN 标签」升级为「shape swap + body 改写 + canonical stride + 在 call site 插入 tensor.as_layout 桥接」。
5. 新增虚 op tensor.as_layout：纯元数据 reinterpret，连接 orch 侧 ([N,K] ND) 与 InCore 侧 ([K,N] DN)。codegen 不发射指令；Simplify 可折叠相邻 as_layout 链。
6. 简化 codegen：删除 EmitMakeTensorViews 的隐式 swap、tile.load / tile.store 的 dn_swap、has_explicit_stride 分支。
7. 扩展 OptimizeOrchTensors / tensor.slice 类型推导：从父 layout 继承到子（父 ND→子 ND，父 DN→子 DN，落入对应 strided 家族）。
8. 用户代码迁移说明：matmul B^T 用户代码无需修改（pass 自动转 canonical 并插入 as_layout）；新增显式 pl.Tensor[[K, N], pl.DN] 写法供希望在 IR 上直接表达 canonical 形式的用户使用。

[lyfne123]

RFC 补充：进一步收紧 layout 与转置 API

基于 #1300 (comment) 的设计，
提议两个进一步的 API 简化，与 §1–§6 的 canonical 设计内在一致。两条提议都不改变 IR 不变量
本身，只收紧用户面表达。

---

补充 1：layout 不再作为用户面 API 暴露

设计动机

RFC §2.1 把 layout 重新定位为「stride 模式标签，与 stride 一致；不可独立变化」。
这意味着对 tensor 类型，layout 在 (shape, stride) 给定后是可推导的：

stride[-1] == 1  ∧  stride[k] == stride[k+1] · shape[k+1]    →  ND-packed
stride[-1] == 1  ∧  stride[-2] >= shape[-1]                  →  ND-strided
stride[-2] == 1  ∧  stride[-1] == shape[-2]                  →  DN-packed
stride[-2] == 1  ∧  stride[-1] >= shape[-2]                  →  DN-strided

既然可推导，把它作为用户输入会出现「两种方式说同一件事」——RFC 想消除的根源歧义会
从「shape 双重含义」换成「(stride, layout) 不一致」。

此外，§3.2 的 pl.Tensor[[K, N], pl.FP32, pl.DN] 写法在 §4.2「runtime 永远行主序」
约定下，要求用户脑子里同时持有两套坐标：

视角	shape	含义
用户写的 pl.Tensor[[K, N], pl.DN]	[K, N]	IR 逻辑视图
Runtime 实际传入的 torch tensor	[N, K]	行主序物理 buffer

这恰是 RFC 试图消灭的 shape 双重含义的另一种形态——只是从「pass 内隐式 swap」
变成「runtime 与 IR 之间隐式 swap」。让用户写 pl.DN 等于把这个负担推给用户。

设计提议

A. 取消用户面 pl.Tensor[..., pl.DN] 写法（即取消 §3.2 的「破坏性变更入口」）

# ❌ 不再合法
b: pl.Tensor[[K, N], pl.FP32, pl.DN]

# ✅ 三种合法表达（覆盖所有 DN 出场场景）
b: pl.Tensor[[N, K], pl.FP32]                # 源张量 shape，默认 ND
xt = pl.transpose(x, 0, 1)                   # op 推导出 DN
b_sub = pl.slice(b_dn_from_op, ...)          # 类型继承

B. layout 在 IR 内部仍保留——作为 verifier 用的 assertion tag，不再是主描述符

// 内部 API 保留 TensorView { stride, layout }
// verifier 强制：layout 必须与 stride 公式一致
INTERNAL_CHECK(DeriveLayoutFromStrides(shape, stride) == layout)
    << "layout tag inconsistent with stride";

C. 处理 RFC Open Question 2（符号 stride）

只在「stride[-2] == 1 但 stride[-1] >= shape[-2] 无法静态验证」时，layout 作为
IR 内部约束注解（IR builder 层），不进入 DSL。

D. tile 端的 fractal layout（NZ / ZN / NN / ZZ）也无须用户直接写

用户面 tile 来源是 pl.move(target_memory=...)，fractal layout 由
ResolveBackendOpLayouts + target_memory 推导。

收益对照

项目	暴露 layout	隐藏 layout
用户心智	需理解 row-major ↔ DN 视图相	永远写源张量 shape，转置交给 op
(stride, layout) 一致性	用户可写出不一致组合	verifier 不变量自动维护
§3.2 类破坏性入口	存在	消除
matmul B^T 用户代码	不变	不变

核心论点：在 canonical 设计里，layout 是 stride 的派生属性；让用户写 layout
等于让用户参与维护一个本应由 verifier 自动维护的不变量。

---

补充 2：弃用 pl.load(..., transpose=True)，改用 pl.transpose + pl.load

设计动机

在 canonical 设计里，所有视图变换都是产生新 tensor SSA 的 op：

视图变换	表达形式	输出 layout
切片	pl.slice(b, ...)	strided 家族
reshape	pl.reshape(b, ...)	推导
转置（orch）	pl.transpose(b, 0, 1)	DN
转置（InCore，载入前）	pl.load(b, transpose=True)	flag！

transpose=True 是唯一一个「视图变换被混进了内存搬运 op 里」的写法，破坏了
pl.slice / pl.reshape / pl.transpose 的 op 正交性。

设计提议

# ❌ 当前
tile_b = pl.load(b, offsets=[0, 0], shapes=[N, K],
                 target_memory=pl.MemorySpace.Mat, transpose=True)

# ✅ 提议
bt = pl.transpose(b, 0, 1)                                    # [N,K] ND -> [K,N] DN
tile_b = pl.load(bt, offsets=[0, 0], shapes=[K, N],
                 target_memory=pl.MemorySpace.Mat)

读起来更直接：「先把 b 看作转置视图，再从这个视图 load 一个 tile」。
pl.transpose 是元数据 reinterpret，与「InCore 不能创建 tensor」不冲突——
它不分配内存，与 tensor.as_layout 同一性质。

与 RFC §3.3 的协同

LowerTransposeLoadParamLayout pass 大幅简化。当前 pass 要做四件事：

1. InCore 形参 shape swap
2. body 内 pl.load 改写（消化 transpose=True）
3. 物化 stride
4. call site 插 as_layout

transpose + load 之后，前两步不再需要——用户写的就是 canonical 形式：

# 用户在 InCore 直接写
def matmul_btranspose(self, b: pl.Tensor[[N, K], pl.FP32], ...):
    bt = pl.transpose(b, 0, 1)
    tile_b = pl.load(bt, offsets=[0, 0], shapes=[K, N], target_memory=Mat)

InCore 形参类型不变（仍是 [N, K] ND），pl.transpose 自身就承担「视图重解释」。
pass 退化为 MaterializeTensorStrides；tensor.as_layout 的出场频率显著下降——
仅在「runtime ND 但 InCore 形参声明 DN」的兼容场景出现，而补充 1 已禁用用户面
pl.DN，这种场景也消失。

各场景对照

# matmul B^T
def matmul_btranspose(self, b: pl.Tensor[[N, K], pl.FP32], ...):
    bt = pl.transpose(b, 0, 1)
    tile_b = pl.load(bt, ..., shapes=[K, N], target_memory=Mat)

# matmul A^T
def matmul_atranspose(self, a: pl.Tensor[[K, M], pl.FP32], ...):
    at = pl.transpose(a, 0, 1)
    tile_a = pl.load(at, ..., shapes=[M, K], target_memory=Mat)

# matmul 双转置 —— 完全对称，不再有「左右两侧 swap 隐式协调」
def matmul_abtranspose(self, a: pl.Tensor[[K, M], ...], b: pl.Tensor[[N, K], ...]):
    at = pl.transpose(a, 0, 1)
    bt = pl.transpose(b, 0, 1)
    tile_a = pl.load(at, ..., shapes=[M, K], target_memory=Mat)
    tile_b = pl.load(bt, ..., shapes=[K, N], target_memory=Mat)

# 转置后多次 load —— view 可复用
bt = pl.transpose(b, 0, 1)
tile_b1 = pl.load(bt, offsets=[0, 0],   shapes=[K, N0], target_memory=Mat)
tile_b2 = pl.load(bt, offsets=[0, n0],  shapes=[K, N1], target_memory=Mat)

反对意见与回应

反对	回应
transpose=True 是硬件 fused load-transpose 的暗示	canonical 化后 transpose 是元数据 reinterpret，无运行期动作；硬件是否利用 stride 走 cube MMU 转置属 ResolveBackendOpLayouts / codegen 的 pattern match，不应留在 DSL 层
两行代码比一行长	多一行换来正交性、可复用 view、pass 复杂度下降
向后兼容	兼容期内允许 transpose=True 作为 transpose + load 的语法糖（解析期立即 lower），最终 deprecated 移除
pl.transpose 能否出现在 InCore	可以——元数据 reinterpret，不分配内存，与 InCore「不能创建 tensor」不冲突

---

两条提议的协同效应

组合后，用户面只需表达三件事：

用户意图	API
「我有一段 row-major 内存」	pl.Tensor[[..., M, N], pl.FP32]（无 layout 参数）
「我想转置这个视图」	pl.transpose(t, axis_a, axis_b)（产生 DN）
「我想切片 / reshape / load」	pl.slice / pl.reshape / pl.load（无 transpose=True）

pl.DN 和 transpose=True 都从 DSL 消失。layout 概念彻底变为 IR 内部派生标签，
由 op 推导维护、由 verifier 强制不变量。

---

Open Questions 增补

• Q4：是否同时移除用户面 pl.Tensor[..., pl.DN] 写法（取消 §3.2 的破坏性变更入口）？
• Q5：是否同时弃用 pl.load(..., transpose=True)，由 pl.transpose + pl.load 替代？

[YunjiQin]

关于补充 1.D：tile fractal layout 不能完全由 target_memory 推导

D 这一点不可行。fractal layout 的选择在某些场景下是程序意图，
而不是「目标内存空间」唯一决定的属性。下面两个场景说明 target_memory 不充分：

场景 1：UB 上的 ND → NZ 转换（同一目标内存）

tpush 到 AIC 之前，常常需要在 UB 上用 move 把同一片 UB 数据从 ND 重排为 NZ：

# 起点：UB 上的 [N, M] ND tile（来自上游算子的 vec 输出）
ub_nd: Tile[[N, M], FP16, MemSpace=Vec, BLayout=Row, SLayout=NoneBox]

# 目标：tpush 给 cube 之前，先在 UB 内 move 成 NZ
ub_nz = pl.move(ub_nd, target_memory=pl.MemorySpace.Vec, layout=pl.NZ)
#                                    ^^^^^ 还在 UB             ^^^^ 必须用户/前端指定

这里 target_memory 仍是 Vec（UB），但 move 必须把 layout 从 ND 切到 NZ。
仅凭 target_memory=Vec 推不出「应该是 NZ」——同一个 UB 上既可以放 ND 也可以放 NZ。
fractal 选择是算子的下一步意图（要送给 cube），不是 move 的目标内存空间。

场景 2：跨 mem space 的 move 可同时调整 layout

跨 mem space 的 move 也允许在搬运的同时换 layout。例如：

# UB ND → L1 NZ（一次 move 完成搬运 + 重排）
l1_nz = pl.move(ub_nd, target_memory=pl.MemorySpace.L1, layout=pl.NZ)

# 同样的 target_memory=L1，也可以是 ZN（右操作数）：
l1_zn = pl.move(ub_nd, target_memory=pl.MemorySpace.L1, layout=pl.ZN)

提议

保留 fractal layout（NZ/ZN/NN/ZZ）作为 move 类 op 的显式 kwarg，理由：

1. fractal 选择是 op 的语义参数，不是类型的固有属性——同一 tile 的「下一步去哪」决定了它现在该用什么 fractal。
2. fractal pattern 在 (shape, stride) 上不可表达（RFC §2.2 表已注明），verifier 无法从 stride 反推；这与 ND/DN 不同。
3. ResolveBackendOpLayouts pass 仍可承担「上下游 fractal 一致性传播」「转置场景翻转」等推导，但出发点是 user-stated fractal，不是从 target_memory 凭空生出。

具体写法：

# move op 接受 layout kwarg；省略时按上下文默认（pass 推导）
ub_nz = pl.move(ub_nd, target_memory=pl.MemorySpace.Vec, layout=pl.NZ)  # 显式
l0a_tile = pl.move(l1_nz, target_memory=pl.MemorySpace.L0A)             # 缺省，pass 按 left-operand 默认 ZZ