README: state the compiler direction; correct five stale claims - #647
Merged
Merged
Conversation
…aims
The README is where the four-layer diagram is pulled from, and it did not
say where the compiler is going -- so it read as if the Python backend
path were the architecture rather than a bootstrap compiler being pruned.
Adds the direction: MLIR/LLVM is the architecture, the Python
per-backend packagers are bootstrap and are the prune target, and this
is the backend half of E2E-REAL-6 ("one compiler authority") -- so it
inherits that program's rule that duplicate lowering authorities are
removed only after the survivor is proven to carry what they carried
(Decision #31's ordering caveat), never by deletion first.
Fast paths stay legitimate. What changes is that they must arrive
through a standard interface -- a declared Target IR op naming the
boundary, so Decision #28's arbiter can tell compiler-generated from
delegated work -- rather than a silent Python-side branch.
`tessera_x86.abi_call` is the shipped precedent; the NVIDIA/ROCm
equivalents are the enabling step that must land BEFORE the prune,
because several legitimate fast paths live inside the bootstrap path
today and have nowhere else to go. Cross-linked to the three-tier
arbiter section so the two are read together: a hand-tuned kernel keeps
its place as a Tier-3 candidate; what it loses is being reached as an
unmeasured fallback because a tool was missing.
Corrections found while reviewing:
- The IR stack diagram listed `tessera.queue.*` barriers. That dialect
was deleted 2026-08-10 as dead IR (Decisions #29/#31); only Attn
remains under Dialect/.
- The NVIDIA pipeline row said sm_120 executes "not through this IR
pipeline", describing only the ptx_emit bootstrap lane. The canonical
matmul now compiles Graph->Schedule->Tile through tessera-opt and
packages via tessera-nvidia-opt + mlir-opt. Also records that this
needs ENABLE_CUDA=ON with BUILD_NVIDIA_BACKEND=ON, since a CUDA-less
NVIDIA build yields a lean driver whose scheduled lanes all fail
having touched no GPU.
- The x86 row attributed the artifact-only AMX lane to "no AMX hardware
in the fleet". It is artifact-only by direction: AMX is retired,
superseded by ACE.
- ROCm build/validate comments said "TheRock ROCm 7.14" / "ROCm 7.2.4";
measured on Princess-Luna: HIP 7.15 (ROCm 10 series).
- Two stale test counts (~14,400) contradicted the README's own stated
policy four paragraphs earlier that counts are not quoted because they
drift. The real figure had drifted by several thousand.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 90fa68e7a1
ℹ️ 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".
The direction is settled (prune the Python bootstrap backend path, build the core through MLIR/LLVM), so the question that now blocks it is coverage: which families does the mainline compiler already serve, and which would lose their only lowering? This derives that from the live sources and drift-gates it, because the point is to watch a gap close and a hand table would be stale by the second landing. Measured: 49 package_* functions across four backends, of which 34 are bootstrap (they take a GraphIRModule and emit target code, bypassing Schedule and Tile) and 15 are compiled-route packagers that consume an already-lowered artifact and are NOT prune targets. Of 24 classified families, 6 resolve to a compiled admission predicate and 18 do not. The classification is by first-parameter type, not by name. A first version keyed on the name suffix and wrongly counted six compiled-route packagers -- package_scheduled_attention and siblings -- as bootstrap surface, overstating the prune. GraphIRModule vs Scheduled*Artifact is a data-flow fact; the name is a convention. Counts are AST-derived. The one thing that cannot be derived is which compiled predicate serves which family, since that lives in driver.py control flow -- so it is declared and VERIFIED: a renamed predicate raises rather than reporting a family as covered. That is the single error that would make a prune silently lossy, so it fails closed, and a test asserts the guard actually fires. The doc states the only two ways a family may leave the table -- absorbed by the mainline compiler, or re-expressed through a declared Target IR boundary so the Decision #28 arbiter can score it -- so it cannot be read as a delete-list.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The README is where the four-layer diagram came from, and it didn't say where the compiler is going — so it read as if the Python backend path were the architecture rather than a bootstrap compiler being pruned.
The direction, stated
MLIR/LLVM is the architecture; the Python per-backend packagers are bootstrap and are the prune target. This is the backend half of E2E-REAL-6 ("one compiler authority"), so it inherits that program's rule: duplicate lowering authorities are removed only after the survivor is proven to carry what they carried (Decision #31's ordering caveat), never by deletion first.
Fast paths stay legitimate — inline PTX, GCN assembly, Tessera Standard Library natives. What changes is that they must arrive through a standard interface: a declared Target IR op naming the boundary, so Decision #28's arbiter can tell compiler-generated from delegated work.
tessera_x86.abi_callis the shipped precedent.The ordering is the load-bearing part. The NVIDIA/ROCm equivalents must land before the prune, because several legitimate fast paths live inside the bootstrap path today and have nowhere else to go. Prune first and you delete capability.
Cross-linked to the three-tier arbiter section so the two read together: a hand-tuned kernel keeps its place as a Tier-3 candidate; what it loses is being reached as an unmeasured fallback because a tool was missing. Chosen, not defaulted into.
Five stale claims corrected
tessera.queue.*barriersAttnremains underDialect/ptx_emitbootstrap lane. The canonical matmul compiles Graph→Schedule→Tile throughtessera-opt, packaged viatessera-nvidia-opt+mlir-optThe NVIDIA row also now records that the compiled lane needs
ENABLE_CUDA=ONwithBUILD_NVIDIA_BACKEND=ON; a CUDA-less NVIDIA build yields a lean driver whose scheduled lanes all fail having touched no GPU.Verification
Documentation-only.
claim_lint --checkclean,lint_docs.shpassed, generated-doc drift 27/27 in sync, surface audits 24 passed / 0 failed. Version claims measured on the boxes rather than recalled.🤖 Generated with Claude Code