ROCm: map the executing lane frontend-to-hsaco, and price W1.1's adoption cost

[gstoner]

Docs only. W1.1 has been sized as "compiler-contract work on the Tile IR" without anyone stating which executing lane traverses Tile IR. I measured it. The answer changes the sequencing, so it gets its own reference doc.

Two GEMM lanes exist; only one runs

Lane A — the directive lane. This is production (11 callers). Python composes a one-op MLIR string that is already at Target IR:

"tessera_rocm.wmma_gemm"() {name, m, n, k, mt, nt, dtype, …}
  → generate-wmma-gemm-kernel        (synthesizes gpu.func directly)
  → lower-tile-to-rocm{arch}         (NO-OP on the default path)
  → lower-tessera-target-to-rocdl → gpu-to-rocdl → hsaco

No Graph IR. No Schedule IR. No Tile IR.

Lane B — the canonical lane. Starts from real tessera.matmul Graph IR, runs tessera-tiling + tessera-tile-ir-lowering. It has one caller in the whole tree, and it is benchmarks/rocm/benchmark_rocm_canonical_gemm_kloop.py.

So the Graph-IR lane has zero production callers, and Schedule IR is absent from every pipeline (0 references; TesseraPM isn't linked into tessera-opt) — consistent with the plan's own note that those passes are annotation-only skeletons. On the lane that runs, the "four-layer stack" is one layer: Target IR.

The expander population prices the rest

measure	count
Generate*.cpp in the ROCm backend	71
distinct generate-* passes the runtime drives	58
expanders consuming tile.view / tile.fragment_pack	0
runtime pipelines including lower-tile-to-rocm	4 of 9

What follows — stated plainly, because the plan implies otherwise

• W1.1 affects no executing ROCm kernel today. lower-tile-to-rocm is in the production pipeline and is a verified no-op there — runtime.py's own comment records byte-identical hsaco with and without it. A capability with no producer: the shape Decision Apple GPU MLA: native f16/bf16 for the absorbed decode kernel #29 exists to flag.
• Step 3 migrates 1 of 58 expanders. Step 5 sits behind the other 57, not behind two more numbered steps.
• The W1.1 row's 5w covers building the contract, not adopting it. Adoption scales with the expander population.

This doesn't make W1.1 wrong — a composable typed lowering is a precondition for any adoption, and steps 0/3a removed two real blockers. It means the adoption policy is an unpriced project-endpoint decision, so the doc names three options rather than assuming the first:

(a) migrate all 58 — the only option that makes the layered-stack claim true for ROCm; (b) migrate the performance-critical family only (GEMM, flash-attn, linear-attn), documenting the long tail as direct Target-IR expanders; (c) treat Tile IR as an optional lane for ops that benefit from shared tiling/pipelining.

Decision #28's three-tier model is compatible with (b) and (c). The current plan text implies (a) without pricing it. That's your call, not mine — the doc lays out the costs and stops.

Also flagged: Lane B is compiled, exercised only by a benchmark, and needs its own decision — canonical front door, declared oracle with a differential test (Decision #31), or not carried.

Linked from the ROCm queue and the plan's open-work list so it's reachable from the Decision #26 entry points. Every number has its re-run command in §6.

Gates

14448 unit passed · ruff clean · 24 generated docs in sync

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 95860c9d69

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".