[Bug] Matmul Acc (L0C) TileType is never stamped CompactMode::normal, so a runtime-narrowed M stores at the wrong fractal stride

[zhangqi-chen]

Background

In pypto-lib, a pl.matmul / pl.matmul_acc chain whose left operand carries a
runtime valid_shape row count on a2a3 has a precision problem: the rows
that ARE valid come back wrong -- 30720 of 32768 valid elements, with only the
first 16 columns of each block correct and the zero tail correct.

Reproduce with:

python repro_matmul_acc_validshape.py -p a2a3 -d <device>

The repro case is not committed. Save the file below at the pypto-lib repo
root as repro_matmul_acc_validshape.py; it needs only pypto and pypto-lib's
golden/ harness (hw-native-sys/pypto-lib at 2cd5f828).

Reproduction case — repro_matmul_acc_validshape.py (save at the pypto-lib repo root)

"""Minimal repro: a runtime-narrowed matmul accumulator corrupts its VALID rows.

One INT8 matmul per core, K consumed by pl.matmul + pl.matmul_acc inside a
pl.pipeline.  The left operand is loaded with `valid_shape=[rows, K_TILE]` where
`rows` is a RUNTIME scalar read from a tensor.

`mad` is issued with M = the left tile's VALID rows, so the hardware lays the
L0C result out with an N-fractal stride of ceil(M/16)*16 = 16.  `TSTORE` reads
it back with `srcStride = TileData::Rows` -- the compile-time PHYSICAL 64 --
because pypto never stamps `CompactMode::normal` on the Acc tile.  Writer 16 vs
reader 64 is a factor-4 skew: store N-fractal j picks up matmul N-fractal 4j, so
only j=0 (the first 16 columns) survives.

    MM_FIX=0  python matmul-acc-runtime-validshape.py -p a2a3 -d 0   -> FAIL
    MM_FIX=1  python matmul-acc-runtime-validshape.py -p a2a3 -d 0   -> FAIL

MM_FIX=1 adds `pl.set_validshape(acc, rows, N_TILE)` before the store and fails
byte-identically: it moves the valid mask, not the physical `Rows` that TSTORE
keys off.

Rewriting `CompactMode::Null` to `CompactMode::Normal` on the Acc tiles in the
generated `<work_dir>/kernels/aic/mm_acc.cpp` and replaying with
`--runtime-dir <work_dir>` turns the FAIL into PASS.
"""
import os

import pypto.language as pl

BLOCKS = 8
M_TILE = 64          # nominal rows per block
VALID = 16           # runtime-valid rows (passed in through `rows`)
K = 2048
N_TILE = 256
K_TILE = 512
FIX = int(os.environ.get("MM_FIX", "0"))


@pl.jit
def mm_acc_validshape(
    x: pl.Tensor[[BLOCKS * M_TILE, K], pl.INT8],
    w: pl.Tensor[[BLOCKS * N_TILE, K], pl.INT8],
    rows: pl.Tensor[[BLOCKS, 1], pl.INT32],
    y: pl.Out[pl.Tensor[[BLOCKS * M_TILE, N_TILE], pl.INT32]],
):
    for b in pl.spmd(BLOCKS, name_hint="mm_acc", allow_early_resolve=True):
        m0 = b * M_TILE
        n0 = b * N_TILE
        v = pl.min(M_TILE, pl.read(rows, [b, 0]))
        xk0 = pl.slice(x, [M_TILE, K_TILE], [m0, 0], valid_shape=[v, K_TILE])
        wk0 = pl.slice(w, [N_TILE, K_TILE], [n0, 0])
        acc = pl.matmul(xk0, wk0, b_trans=True, out_dtype=pl.INT32)
        for k0 in pl.pipeline(K_TILE, K, K_TILE, stage=2):
            xk = pl.slice(x, [M_TILE, K_TILE], [m0, k0], valid_shape=[v, K_TILE])
            wk = pl.slice(w, [N_TILE, K_TILE], [n0, k0])
            acc = pl.matmul_acc(acc, xk, wk, b_trans=True)
        if FIX == 1:
            y[m0 : m0 + M_TILE, :] = pl.set_validshape(acc, v, N_TILE)
        else:
            y[m0 : m0 + M_TILE, :] = acc
    return y


def build_tensor_specs():
    import torch
    from golden import TensorSpec

    g = torch.Generator().manual_seed(7)
    xi = torch.randint(-127, 128, (BLOCKS * M_TILE, K), generator=g, dtype=torch.int32).to(torch.int8)
    wi = torch.randint(-127, 128, (BLOCKS * N_TILE, K), generator=g, dtype=torch.int32).to(torch.int8)
    rows = torch.full((BLOCKS, 1), VALID, dtype=torch.int32)
    return [
        TensorSpec("x", [BLOCKS * M_TILE, K], torch.int8, init_value=lambda: xi),
        TensorSpec("w", [BLOCKS * N_TILE, K], torch.int8, init_value=lambda: wi),
        TensorSpec("rows", [BLOCKS, 1], torch.int32, init_value=lambda: rows),
        TensorSpec("y", [BLOCKS * M_TILE, N_TILE], torch.int32, is_output=True),
    ]


def golden(tensors):
    import torch

    xf = tensors["x"].to(torch.float64)
    wf = tensors["w"].to(torch.float64)
    out = torch.zeros(BLOCKS * M_TILE, N_TILE, dtype=torch.float64)
    for b in range(BLOCKS):
        m0, n0 = b * M_TILE, b * N_TILE
        xb = xf[m0 : m0 + M_TILE].clone()
        xb[VALID:] = 0.0                      # valid_shape zero-pads the tail
        out[m0 : m0 + M_TILE] = xb @ wf[n0 : n0 + N_TILE].T
    tensors["y"][:] = out.to(torch.int32)


if __name__ == "__main__":
    import argparse
    from golden import run_jit

    ap = argparse.ArgumentParser()
    ap.add_argument("-p", "--platform", default="a2a3")
    ap.add_argument("-d", "--device", type=int, default=0)
    ap.add_argument("--compile-only", action="store_true", default=False)
    ap.add_argument("--runtime-dir", default=None)
    a = ap.parse_args()
    print(f"[REPRO] M_TILE={M_TILE} runtime valid rows={VALID} MM_FIX={FIX}")
    r = run_jit(fn=mm_acc_validshape, specs=build_tensor_specs(), golden_fn=golden,
                compile_only=a.compile_only, runtime_dir=a.runtime_dir,
                runtime_cfg=dict(platform=a.platform, device_id=a.device),
                rtol=0, atol=0)
    if not r.passed:
        print(r.error or "")
        raise SystemExit(1)

Reproduction environment:

Component	Version
pypto-lib	2cd5f828 (branch: main)
pypto	3617ebbd (branch: detached)
simpler	3165cc89 (branch: detached)
ptoas	0.57
pto-isa	83d01313
CANN	9.0.0

All four components are on their pinned versions (runtime gitlink,
runtime/pto_isa.pin, toolchain/versions.env) -- no mismatch.

Also reproduces byte-identically on current pypto main 42376d0d
(with its pinned simpler 1f27a157 and pto-isa f51c92f6), so this is not
already fixed upstream.

Diagnosis: pypto -- the Acc (L0C) TileType deduced by
src/ir/op/tile_ops/matmul.cpp is built with valid_shape rows smaller than its
physical rows but is never stamped CompactMode::normal, so the PTO-ISA store
reads L0C at a different fractal stride than mad wrote it at. A secondary gap
in pto-isa is noted at the end.

Description

mad and TSTORE disagree about the L0C N-fractal stride whenever a matmul's
left operand has a runtime valid row count below its physical row count.

Writer. TMATMUL_IMPL takes M from the valid rows of the L0A tile and
passes it straight to mad, which lays the result out in L0C with an N-fractal
stride of ceil(M/16)*16. Nothing on this path consults TileRes::Rows
(pto-isa/include/pto/npu/a2a3/TMatmul.hpp):

uint16_t m = aMatrix.GetValidRow();          // 16
uint16_t k = aMatrix.GetValidCol();
uint16_t n = bMatrix.GetValidCol();
TMatmul<...>(cMatrix.data(), aMatrix.data(), bMatrix.data(), m, k, n, kDirectionAlign);
// -> mad(c, a, b, m, k, n, ...)

Reader. TStoreAccNz2nd uses the tile's compile-time physical Rows,
switching to the valid-row stride only for a compact tile
(pto-isa/include/pto/common/arch/memory/tstore_common.hpp):

uint16_t srcStride  = TileData::Rows;                  // 64
uint16_t srcNdStride = TileData::Rows * c0 * gShape4;
if constexpr (TileData::Compact == CompactMode::Normal) {
    srcStride = (validRow + FRACTAL_NZ_ROW - 1) / FRACTAL_NZ_ROW * FRACTAL_NZ_ROW;   // 16
    srcNdStride = srcStride * gShape4 * c0;
}

Why the flag is never set. DeduceTileMatMulType and
DeduceTileMatMulAccType (src/ir/op/tile_ops/matmul.cpp) build the Acc
TileView with physical_shape = {lhs physical M, rhs physical N} and
valid_shape = {lhs valid M, rhs valid N}, then leave tile_view.compact at its
CompactMode::null default:

TileView tile_view;
tile_view_semantics::SetTileLayout(
    tile_view, tile_view_semantics::GetImplicitTileLayout(geometry.physical_shape, MemorySpace::Acc));
tile_view.valid_shape = geometry.valid_shape;
return std::make_shared<TileType>(std::move(geometry.physical_shape), geometry.accumulator_dtype,
                                  std::nullopt, tile_view, MemorySpace::Acc);

The only place in the compiler that sets CompactMode::normal is the L0A/L0B
tile.extract deducer (src/ir/op/tile_ops/transform.cpp, added for #2232). The
same reasoning was never extended to L0C -- and the contrast is visible on two
adjacent lines of the generated kernel for this repro, where the L0A operand of a
matmul is compact but its own accumulator is not:

// pto: %acc__tile_l0_a
Tile<TileType::Left, int8_t, 64, 128, ..., CompactMode::Normal> v60 = ...(v39, v9);
// pto: %acc__tile_l0_c_first
Tile<TileType::Acc, int32_t, 64, 256, ..., CompactMode::Null>   v70 = ...(v39, v11);
//                                         ^^^^^^^^^^^^^^^^^^^  v39 = min(runtime_rows, 64) = 16

Consequence. Writer stride 16 vs reader stride 64 is a factor-4 skew, so the
store's N-fractal j picks up the matmul's N-fractal 4j. j = 0 is correct and
everything above it is wrong or never written -- exactly the observed
2048-correct / 30720-wrong split.

There is no compile diagnostic and no runtime error. valid_shape with a
compile-time constant is unaffected, because the physical shape narrows with it
and both sides agree. pl.set_validshape on the result before the store does not
help either (MM_FIX=1 in the repro): it moves the valid mask, not the physical
Rows that TSTORE keys off.

Steps to Reproduce

1. Save the repro above at the pypto-lib repo root as repro_matmul_acc_validshape.py.
2. Run MM_FIX=0 python repro_matmul_acc_validshape.py -p a2a3 -d <device>.
3. Observe the golden comparison FAIL.

To confirm the diagnosis without changing any DSL:

4. Compile once (--compile-only) and note the work dir printed under build_output/.
5. In <work_dir>/kernels/aic/mm_acc.cpp, rewrite CompactMode::Null to
   CompactMode::Normal on the 12 Tile<TileType::Acc, int32_t, 64, 256, ...>
   declarations. (Patch kernels/aic/, not ptoas/ -- the latter is the ptoas
   input and is not what gets compiled.)
6. Replay with --runtime-dir <work_dir>; the run now PASSes.

Expected Behavior

The valid rows of the product are correct, and the narrowing does real work: a
16-row TLOAD, mad with M=16, and a 16-row TSTORE. The whole point of a
runtime valid_shape on the left operand is to skip the redundant rows.

Actual Behavior

The sizes are all correct -- the generated kernel really does load 16 rows, issue
mad with M=16, and store 16 rows -- but the stored values are scrambled:

[RUN]   'y' FAIL  shape=(512, 256) dtype=torch.int32
Output(s) does not match golden: ['y']
  'y' FAIL  shape=(512, 256) dtype=torch.int32
    Mismatched elements: 30720/131072  rtol=0 atol=0
    first 20 mismatches:
    [16] actual=265517, expected=-111003
    [17] actual=174441, expected=-177350
    [18] actual=-54238, expected=264675
    ...

Element 16 is row 0, column 16 -- i.e. the first element of N-fractal 1. N-fractal
0 (columns 0-15) is correct for all 16 valid rows; that is the 2048 elements that
match. The zero-padded tail (rows 16-63) is also correct.

With MM_FIX=1 (a pl.set_validshape(acc, rows, N_TILE) before the store) the
failure is byte-identical.

Suggested Fix

Mirror the tile.extract treatment in the matmul Acc deducers: when the deduced
Acc valid_shape rows are not provably equal to the physical rows, stamp
tile_view.compact = CompactMode::normal. Verified on device via the generated-code
patch described in "Steps to Reproduce" (steps 4-6).

One caveat, which is why this is reported rather than sent as a PR. The store
side of PTO-ISA already honours the flag on every Acc->GM variant
(TStoreAccNz2nd, TStoreAccNz2nz, TStoreAccNz2NC1HWC0), but the Acc->L1
path does not: TExtractAccToMat
(pto-isa/include/pto/npu/a2a3/TExtract.hpp) reads

constexpr uint16_t srcStride = SrcTileData::Rows;

with no CompactMode branch at all. That path is already wrong today for a
runtime-narrowed M, and stamping the flag in pypto will not fix it -- it needs a
matching pto-isa change, and the same sweep should cover a5. Whoever picks this up
should decide whether the two land together.

Git Commit ID

3617ebbd6daf5b94d9d2035c880d6251974deb79 (also reproduces on main at 42376d0)

NPU Kind

a2a3 -- npu-smi reports Ascend910.

Host Platform

Linux (aarch64)

Additional Context

Impact on pypto-lib: this blocks a MoE routed-expert tiling change
(RECV_TILE 16 -> 64) that would let an expert's weights stream once instead of
ceil(rows/16) times. The only correct workaround is to drop valid_shape from
the matmul's left operand and always compute the full nominal tile -- which
forfeits exactly the work-skipping the narrowing was for.

Related, but distinct:

• [Pass Bug] AutoTileMatmulL0: matmul_acc M/N deferral drops the supported K tiling, then fails with a misleading buffer error #2232 -- the tile.extract fix that introduced CompactMode::normal for
  L0A/L0B. Same reasoning, never extended to L0C.
• [Bug] create_l1/gather_row matmul path rejects an A-operand with rows % 16 != 0 (no valid_shape equivalent) #2442 -- also a matmul A-operand with fewer than 16 rows, but a compile-time
  rejection on the create_l1 / gather_row staging path rather than a silent
  L0C stride corruption.

[zhangqi-chen]

The suggested fix is necessary but not sufficient — a second shape stays broken

I implemented the fix suggested above (stamp CompactMode::normal in the three
Acc deducers in src/ir/op/tile_ops/matmul.cpp when the deduced valid rows are
not provably the physical rows) and confirmed it turns the original repro into a
PASS on device. It also leaves expert_routed.py, dspark_proj.py and
dspark/expert_shared.py passing.

But it does not fix the shape the real model kernel actually uses, where the
accumulator is seeded by pl.create_tensor before the K loop and rebound under
an if k0 == 0 branch:

acc = pl.create_tensor([1, M_TILE, N_TILE], dtype=pl.INT32)   # full height
for k0 in pl.pipeline(0, K, K_TILE, stage=2):
    x_k = pl.slice(x, [M_TILE, K_TILE], [m0, k0], valid_shape=[v, K_TILE])   # runtime v
    if k0 == 0:
        acc = pl.matmul(x_k, w_k, b_trans=True, out_dtype=pl.INT32)
    else:
        acc = pl.matmul_acc(acc, x_k, w_k, b_trans=True)
y[m0 : m0 + M_TILE, :] = pl.reshape(acc, [M_TILE, N_TILE])

The pl.matmul / pl.matmul_acc results are narrowed and compact, but the
pre-built tensor and the loop-carried phi that merges with them never go through
a matmul deducer, so the narrowing is lost at the phi and the tile that
actually reaches TSTORE is full height and non-compact. From the generated
kernel (v40 = min(runtime_rows, 64) = 16, v9 = 64):

// pto: %acc__tile_l0_c_first    <- matmul result
Tile<TileType::Acc, int32_t, 64, 256, ..., CompactMode::Normal> v81 = ...(v35, v10);   // valid rows = 16
// pto: %acc__tile_l0_c_acc      <- matmul_acc result
Tile<TileType::Acc, int32_t, 64, 256, ..., CompactMode::Normal> v83 = ...(v35, v10);   // valid rows = 16
// pto: %acc__tile_l0_c_phi      <- loop-carried merge
Tile<TileType::Acc, int32_t, 64, 256, ..., CompactMode::Normal> v29 = ...(v9,  v10);   // valid rows = 64 (!)
// pto: %acc__tile               <- pl.create_tensor seed
Tile<TileType::Acc, int32_t, 64, 256, ..., CompactMode::Null>   v36 = ...(v9,  v10);
// pto: %t__tile                 <- the tile TSTORE reads
Tile<TileType::Acc, int32_t, 64, 256, ..., CompactMode::Null>   v114 = ...(v9, v10);
TSTORE(v118, v114);

The phi takes the seed's full height rather than the reaching definitions'
narrowed height, and the store both reads at the wrong stride and writes 64
rows instead of 16. Device result: 75264 / 131072 mismatched -- worse than
the original repro's 30720, because the 48-row tail is now garbage instead of
untouched zeros.

Note the seed is dead: k0 == 0 assigns unconditionally, so no mad ever reads
it. Widening the loop-carried valid shape back to the seed's height is what loses
the narrowing.

pl.set_validshape does not rescue it either, and produces an illegal store

The documented idiom for pinning a runtime valid extent does not help here,
because acc is a tensor (it came from pl.create_tensor), so
pl.set_validshape lands on the tensor view. The narrowing then reaches the GM
destination view but not the source Acc tile:

// destination: 16 rows
pto::Shape<1, 1, 1, -1, 256> v122 = pto::Shape<1, 1, 1, -1, 256>(v13, v13, v13, v40, v10);   // v40 = 16
// source: still 64 rows, still non-compact
Tile<TileType::Acc, int32_t, 64, 256, ..., CompactMode::Null> v117 = ...(v9, v10);           // v9  = 64
TSTORE(v124, v117);

That pair violates PTO-ISA's own precondition in TStoreAccNz2nd:

PTO_ASSERT(validRow == gShape3, "The validRow of TileData must be equal to Shape3 of ND shape!");

validRow is 64 and gShape3 is 16. The assert is compiled out in the release
build, so it stores silently and wrongly: 30720 / 131072 mismatched, the same
factor-4 N-fractal skew as the original repro.

Repro

Self-contained; CT_FIX=0 is the plain form, CT_FIX=1 adds the
pl.set_validshape attempt. Both FAIL, with the counts above. Save at the
pypto-lib repo root; needs pypto plus pypto-lib's golden/ harness.

Reproduction case — repro_matmul_acc_createtensor_phi.py

"""Repro 2: a create_tensor-seeded accumulator keeps a full-height Acc tile.

Mirrors `expert_routed_t16h_draft.py`'s `exp_gate_mm` block exactly:

    acc = pl.create_tensor([1, M_TILE, N_TILE], dtype=pl.INT32)   # full height
    for k0 in pl.pipeline(0, K, K_TILE, stage=2):
        x_k = pl.slice(..., valid_shape=[v, K_TILE])              # runtime v < M_TILE
        if k0 == 0:
            acc = pl.matmul(x_k, w_k, b_trans=True, out_dtype=pl.INT32)
        else:
            acc = pl.matmul_acc(acc, x_k, w_k, b_trans=True)
    y[...] = pl.reshape(acc, [M_TILE, N_TILE])

The matmul results carry the narrowed valid rows, but the pre-built tensor and
the loop-carried phi that merges with them do not come from a matmul deducer.
If they stay `CompactMode::Null` at full height while the matmul results are
`CompactMode::Normal`, writer and reader disagree on the L0C stride again.

    python matmul-acc-createtensor-phi.py -p a2a3 -d 0

Contrast with `matmul-acc-runtime-validshape.py`, which seeds the accumulator
from the first `pl.matmul` itself and has no `create_tensor` in the chain.
"""
import os

import pypto.language as pl

# CT_FIX=1 re-pins the valid rows on the way out, so the store sees the narrowed
# extent instead of the phi's full height.
FIX = int(os.environ.get("CT_FIX", "0"))

BLOCKS = 8
M_TILE = 64          # nominal rows per block
VALID = 16           # runtime-valid rows (passed in through `rows`)
K = 2048
N_TILE = 256
K_TILE = 512


@pl.jit
def mm_acc_createtensor(
    x: pl.Tensor[[BLOCKS * M_TILE, K], pl.INT8],
    w: pl.Tensor[[BLOCKS, N_TILE, K], pl.INT8],
    rows: pl.Tensor[[BLOCKS, 1], pl.INT32],
    y: pl.Out[pl.Tensor[[BLOCKS * M_TILE, N_TILE], pl.INT32]],
):
    for b in pl.spmd(BLOCKS, name_hint="mm_ct", allow_early_resolve=True):
        m0 = b * M_TILE
        v = pl.min(M_TILE, pl.read(rows, [b, 0]))
        acc = pl.create_tensor([1, M_TILE, N_TILE], dtype=pl.INT32)
        for k0 in pl.pipeline(0, K, K_TILE, stage=2):
            xk = pl.slice(x, [M_TILE, K_TILE], [m0, 0 + k0], valid_shape=[v, K_TILE])
            wk = w[b : b + 1, 0:N_TILE, k0 : k0 + K_TILE]
            if k0 == 0:
                acc = pl.matmul(xk, wk, b_trans=True, out_dtype=pl.INT32)
            else:
                acc = pl.matmul_acc(acc, xk, wk, b_trans=True)
        acc2d = pl.reshape(acc, [M_TILE, N_TILE])
        if FIX == 1:
            acc_v = pl.set_validshape(acc2d, v, N_TILE)
            y[m0 : m0 + M_TILE, :] = acc_v
        else:
            y[m0 : m0 + M_TILE, :] = acc2d
    return y


def build_tensor_specs():
    import torch
    from golden import TensorSpec

    g = torch.Generator().manual_seed(7)
    xi = torch.randint(-127, 128, (BLOCKS * M_TILE, K), generator=g, dtype=torch.int32).to(torch.int8)
    wi = torch.randint(-127, 128, (BLOCKS, N_TILE, K), generator=g, dtype=torch.int32).to(torch.int8)
    rows = torch.full((BLOCKS, 1), VALID, dtype=torch.int32)
    return [
        TensorSpec("x", [BLOCKS * M_TILE, K], torch.int8, init_value=lambda: xi),
        TensorSpec("w", [BLOCKS, N_TILE, K], torch.int8, init_value=lambda: wi),
        TensorSpec("rows", [BLOCKS, 1], torch.int32, init_value=lambda: rows),
        TensorSpec("y", [BLOCKS * M_TILE, N_TILE], torch.int32, is_output=True),
    ]


def golden(tensors):
    import torch

    xf = tensors["x"].to(torch.float64)
    wf = tensors["w"].to(torch.float64)
    out = torch.zeros(BLOCKS * M_TILE, N_TILE, dtype=torch.float64)
    for b in range(BLOCKS):
        m0 = b * M_TILE
        xb = xf[m0 : m0 + M_TILE].clone()
        xb[VALID:] = 0.0                      # valid_shape zero-pads the tail
        out[m0 : m0 + M_TILE] = xb @ wf[b].T
    tensors["y"][:] = out.to(torch.int32)


if __name__ == "__main__":
    import argparse
    from golden import run_jit

    ap = argparse.ArgumentParser()
    ap.add_argument("-p", "--platform", default="a2a3")
    ap.add_argument("-d", "--device", type=int, default=0)
    ap.add_argument("--compile-only", action="store_true", default=False)
    ap.add_argument("--runtime-dir", default=None)
    a = ap.parse_args()
    print(f"[REPRO] M_TILE={M_TILE} runtime valid rows={VALID} CT_FIX={FIX} (create_tensor-seeded acc)")
    r = run_jit(fn=mm_acc_createtensor, specs=build_tensor_specs(), golden_fn=golden,
                compile_only=a.compile_only, runtime_dir=a.runtime_dir,
                runtime_cfg=dict(platform=a.platform, device_id=a.device),
                rtol=0, atol=0)
    if not r.passed:
        print(r.error or "")
        raise SystemExit(1)

What this means for the fix

Stamping the compact flag in the matmul deducers is correct as far as it goes,
but it only covers accumulators whose type is produced by a matmul. A complete
fix also has to keep the narrowed valid rows alive across the loop-carried phi
(or refuse to merge a narrowed Acc with a full-height one), and make the
tensor-level valid-shape narrowing reach the Acc tile rather than only the GM
view. I did not attempt either -- both look like they need a decision from
someone who owns the phi typing and the tensor-to-tile lowering, rather than a
one-line stamp.

Environment as in the issue body, re-verified on pypto 88341d3f (main) with
simpler 93adc386, pto-isa cd4a3d3f, ptoas 0.57, CANN 9.0.0, a2a3.

[lyfne123]

Confirmed on merged main, and the root cause is one systemic assumption rather than a phi bug

Thanks for the second repro — it reproduces exactly as described, and chasing it turned up
a mechanism that I think changes how this should be scoped.

Re-verified on main at 5b15048e (i.e. with #2474 merged), no local changes,
--codegen-only:

%acc__tile_l0_c_first   valid_row=%18 (runtime)  compact=1     <- pl.matmul, #2474 works here
%acc__phi_v5            valid_row=64             compact=1     <- loop-carried phi
%acc__tile              valid_row=64             compact=0     <- create_tensor seed
%acc2d__tile            valid_row=64             compact=0     <- the tile TSTORE reads

So #2474 is necessary and not sufficient, exactly as you found.

The IR is already invalid by PyPTO's own rules

Before looking for a fix I turned per-pass verification on. The pipeline rejects this
program right after FlattenTileNdTo2D:

pypto.Error: Post-verification failed after pass 'FlattenTileNdTo2D':
[1] ERROR - TypeCheck  Valid shape dimension mismatch in ForStmt: declared iter_arg[0]
    dimension[0] = 64, but yield value[0] dimension[0] = pl.min(v__ssa_v0, 64)   Error Code: 104
[2] ERROR - TypeCheck  ... yield value[0] vs return_var[0]                       Error Code: 104
[3] ERROR - TypeCheck  IfStmt: then yield value[0] vs else yield value[0]        Error Code: 104

Without the instrument the identical program compiles clean. The reason it ships silently is
worth recording on its own: TypeChecked is verified once, at "pipeline_input", and never
again. A structural property is re-verified only when some pass names it in
.produced / .invalidated (src/ir/transforms/passes.cpp:250-273), and no pass in
pass_properties.h mentions TypeChecked. On top of that, at the single check point the
narrowing does not exist yet — tensor.matmul drops the operand valid_shape entirely
(src/ir/op/tensor_ops/matmul.cpp:188), so every acc type is still full height and the check
passes trivially. Only tests/ut/conftest.py installs BEFORE_AND_AFTER, which makes the UT
suite strictly stricter than a real compile.

Where the narrowing is lost

Three places, all "type from the init / one branch, never reconcile":

Site	Behaviour
convert_tensor_to_tile_ops_pass.cpp:381	iter_arg type = the converted seed's type
same, :507-529 (UpdateLoopReturnVars)	loop return_var forced back to the iter_arg's type
same, :430-447	IfStmt phi type = the then branch; else is consulted only if then has no yield

tile.matmul_acc then inherits the (full-height) accumulator operand, so the else branch never
narrows either.

The part that makes this bigger than it looks

AutoTileMatmulL0 already solves the same problem correctly, and not by merging yield types —
it builds a narrowed seed (BuildAccInitWithValidShape, auto_tile_matmul_l0_pass.cpp:369-390)
and mints iter_arg / phi / return_var from it. Its own phi is also then-branch typed, and that is
consistent because the seed is already narrow. I confirmed the same holds here: a kernel with
the identical if/else + pipeline-carry shape, but seeded by a narrowed pl.matmul instead of
pl.create_tensor, compiles to a correct compact store today.

So "narrow the seed" is the right shape of fix. Doing it surfaced the actual blocker:

Most of the pipeline is only correct for tiles whose TileView is implicit (collapsible).

NormalizeImplicitTileView (tile_view_semantics.h:250-255) re-derives the layout triple
(blayout / slayout / fractal) from the memory space only when
IsDefaultPrintedTileView holds — and that predicate returns false for any non-null compact,
any non-null pad, or any valid_shape != shape (:204-216). Deducers that stamp a
shape-derived layout rely on that re-derivation to rescue them. tile.reshape is one:
it always stamps InferImplicitTileLayoutFromShape(new_shape) (flat) and is normally rescued.

Measured on an Acc tile, reshaping [1,64,256] -> [64,256]:

Source view	Collapsible	Layout after tile.reshape
fully valid	yes	col_major / 1024 — Acc NZ, correct
narrowed rows	no	row_major / 512 — flat, wrong
fully valid + compact=normal	no	row_major / 512 — flat, wrong

The third row is the important one: that tile is fully valid. The only thing making it
non-collapsible is compact=normal — which is precisely what #2470's own fix stamps. So:

#2470's fix  ->  Acc tiles carry compact
             ->  those tiles stop collapsing
             ->  code paths that relied on collapse to recover the layout lose their rescue
             ->  whatever layout the local deducer stamped becomes permanent

This is a pre-existing defect in tile.reshape that was simply unreachable before, because
reshape inputs on these paths were always fully-valid Vec tiles.

Prototype status

I have a working prototype (not proposed for merge as-is):

• tile.create gains an optional valid_shape argument, so a narrowed Acc box can be
  declared. This deliberately does not touch tile.set_validshape, whose inherit-only
  behaviour is correct and was fixed for good reason in fix(ir): stamp compact mode on a runtime-narrowed matmul accumulator #2474 review — a metadata-only alias
  must not re-interpret bytes that are already written. A freshly created buffer has no prior
  layout to preserve, so the declaration site is free to derive one.
• A NarrowLoopCarryValidShape pass that re-declares a carry's seed when the yields are
  provably narrower, and re-types the body's def-use closure through the operators' own
  deducers.
• An identity-reshape short-circuit (new_shape == source shape returns the source type).

With those, the store reads
!pto.tile_buf<loc=acc, ..., blayout=col_major, slayout=row_major, fractal=1024, pad=0, compact=1>
with the runtime valid row count — correct on all three axes. UT suite: 10223 passed, 1 expected
failure (test_pass_manager_get_strategy_default asserts the Default pass list, which gained a
pass).

But the identity short-circuit only removes this kernel's instance. Any kernel doing a
non-identity reshape of a narrowed-or-compact Acc tile still gets the flat layout.

The open question

Fixing that properly means deciding who guarantees layout correctness for a tile with an
explicit view:

1. every deducer derives its layout from the memory space the result will inherit (fix
   tile.reshape and audit its peers), or
2. NormalizeImplicitTileView relaxes its gate from "the whole view is default" to "the layout
   triple is default" — valid_shape / compact / pad are orthogonal to blayout /
   slayout / fractal, and arguably should not be coupled to one switch.

(2) looks more correct to me but changes a core IR canonicalization rule, well beyond this
issue. I did not want to make that call unilaterally — it needs whoever owns the tile-view
semantics.

Happy to push the prototype branch if it is useful as a starting point, or to take it further
once the question above is settled.

[lyfne123]

Closing: every shape reported here now compiles to the pitch mad actually wrote at, and all three are covered on hardware.

Shape	Fixed by
The original repro — accumulator seeded by pl.matmul, accumulated in a pl.pipeline	#2474
A plain pl.matmul over a K the compiler splits itself, where AutoTileMatmulL0 synthesizes the seed	#2531
The second repro in the comments — pl.create_tensor seed whose loop-carried phi widened valid_shape back to the full box	#2544

#2544 is the one that closes the gap the other two left. A loop carry was typed from its init value alone — ConvertToSSA mints the IterArg from the reaching definition, ConvertTensorToTileOps re-mints it from the converted seed, and both force the loop's return_var back to that type, so the yields were never consulted and the narrowing died at the loop boundary. The repair re-declares the seed at the extent the yields prove (tile.create(compact=True) plus tile.set_validshape, the form AutoTileMatmulL0 already builds when it splits K) and re-types the body's def-use closure through the operators' own deducers. It runs inside the two passes that create the narrowing — ConvertTensorToTileOps for a 2D seed, FlattenTileNdTo2D for an ND one — so neither publishes IR its own TypeCheck and AccCompactValid verifiers would reject.

It is deliberately narrow: only Acc carries, only a tile.create seed, only a provable narrowing, only where the two readings of the buffer would actually disagree (AccPitchesCoincide, shared with the verifier, so a single-fractal-block [16, N] accumulator keeps the exact form it has today), and only where the narrowed extent is visible before the loop. A carry that fails the last gate is declined rather than hoisted — a row count spelled next to the slice it bounds, inside the body, cannot be named at the seed — and where its pitches genuinely differ AccCompactValid reports a compile error instead of letting it corrupt data.

Verified on a2a3: tests/st/runtime/cross_core/test_c2v_narrowed_acc_epilogue.py runs all three shapes, including a hand-written carried loop added for this one. 13 unit tests, each confirmed failing on the unfixed build.

One thing this does not settle, raised in the analysis above and worth its own issue if anyone hits it: an explicit TileView stops a tile from collapsing, and NormalizeImplicitTileView only re-derives a layout for a view that does. #2544 fixes the identity tile.reshape (it now keeps the whole source view — layout triple, stride, start_offset, memory space), which is what this kernel needed. A rank-changing reshape of a narrowed or compact Acc tile still stamps the shape-derived flat layout and never gets rescued. Settling it means deciding who guarantees layout correctness for a tile with an explicit view: every deducer derives its layout from the memory space the result will inherit, or NormalizeImplicitTileView relaxes its gate from "the whole view is default" to "the layout triple is default". That is a core canonicalization rule, well beyond this issue.