Correct: a CUDA-less NVIDIA build does register the Target IR dialect - #648
Merged
Merged
Conversation
Review finding on #647, and it is correct. I wrote that a CUDA-less NVIDIA build "produces a lean driver that never registers the NVIDIA Target IR dialect". It does register it. src/compiler/codegen/tessera_gpu_backend_NVIDIA/CMakeLists.txt states in its header that TESSERA_BUILD_NVIDIA_BACKEND=ON always builds the hardware-free Target IR spine, and tools/tessera-opt/CMakeLists.txt links TesseraNVIDIAIR/TesseraNVIDIAConversion under `if(TARGET TesseraNVIDIAConversion)` -- not gated on leanness. `_tessera_opt_lean_permitted` names `nvidia-backend` explicitly. What the lean driver omits is the CORE spine (TesseraIR/TesseraPasses), which is why scheduled pipelines are unavailable there -- a different cause with the same surface symptom. The error I actually observed came from a THIRD configuration: The-Super-Bear has TESSERA_BUILD_NVIDIA_BACKEND=OFF, so the dialect was never built. I generalised one box's config into a claim about a different one, and in doing so erased the supported host-free artifact configuration that Decision #19's hardware-free Target IR exists to enable. Both docs now carry the three-way distinction as a table so the configurations cannot be collapsed again. The NVIDIA todo and the two memory notes were already correct -- they said "without the NVIDIA backend" -- so only the README claim was wrong.
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: 5c57ba09b0
ℹ️ 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".
gstoner
added a commit
that referenced
this pull request
Aug 30, 2026
…_ptx Enabling step for the bootstrap prune. The 19 NVIDIA bootstrap packagers contain legitimate fast paths -- vendor libraries, hand-tuned kernels, inline PTX -- and pruning before they have a declared boundary to land on would delete capability. NVIDIA first because it has both the largest gap and working profiling tools; the arbiter is MEASURED, so a boundary on an unprofilable target is bookkeeping. kernel_call was a summary line and nothing else. It inherited the shared attr-dict, so `callee` -- the one fact naming what is delegated to -- rode as an unvalidated discardable attribute; an emitter could name any symbol, or none, and verify. The dialect header says why it existed: to keep Python-emitted IR parseable. It was a parse-compatibility stub for the very packagers being pruned, which is Decision #29's anti-pattern. Both pathways are declared, as two ops rather than one with a mode. kernel_call takes callee/arch/binding/provenance/accuracy; inline_ptx takes ptx/constraints/arch/accuracy/has_side_effects. Separate because the delegate differs in kind -- a binding resolved at link time versus text carried in the artifact -- and their failure modes differ: an empty callee is an unresolved symbol, an empty ptx body is a silently successful no-op. One op with a mode attribute needs a verifier that decides which half of its own attributes to trust. The attributes are the arbiter's inputs, which is what makes this real rather than decoration. `accuracy` is the budget half of "fastest in-budget candidate": tolerance_bounded must state a tolerance, reference_exact must not carry one. Semantic key, never defaults (#21a). Evidence on The-Super-Bear with the full driver: builds clean, positive fixture parses both ops, the new negative fixture rejects 7 cases, and the NVIDIA lit suite is 60/60. Also folds in the review P2 on #648: the lean driver's core spine is LINKED (TesseraPM PUBLIC-links TesseraIR/TesseraScheduleIR) but not REGISTERED. "Not linked" was an inaccurate build diagnosis and would misdirect anyone debugging a lean-driver failure. Not done and stated as such: nothing yet queries these attributes to score a candidate. The verifier is a real consumer, but arbiter integration is the next step, and the ROCm equivalent is still owed.
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.
Review finding on #647, and it's correct.
I wrote that a CUDA-less NVIDIA build "produces a lean driver that never registers the NVIDIA Target IR dialect." It does register it.
src/compiler/codegen/tessera_gpu_backend_NVIDIA/CMakeLists.txtstates in its header thatTESSERA_BUILD_NVIDIA_BACKEND=ONalways builds the hardware-free Target IR contract spine; CUDA only gates the runtime kernels.tools/tessera-opt/CMakeLists.txtlinksTesseraNVIDIAIR/TesseraNVIDIAConversionunderif(TARGET TesseraNVIDIAConversion)— not gated on leanness._tessera_opt_lean_permittednamesnvidia-backendexplicitly.What the lean driver omits is the core spine (
TesseraIR/TesseraPasses), which is why scheduled pipelines are unavailable there — a different cause with the same surface symptom.The error I actually observed came from a third configuration. The-Super-Bear has
TESSERA_BUILD_NVIDIA_BACKEND=OFF, so the dialect was never built at all. I generalized one box's config into a claim about a different one — and in doing so erased the supported host-free artifact configuration that Decision #19's hardware-free Target IR exists to enable.Both docs now carry the distinction as a table:
ENABLE_CUDA=ONrequires the registered NVIDIA Target IR dialectThe NVIDIA todo and both memory notes were already correct — they say "without the NVIDIA backend" — so only the README claim was wrong.
Docs only.
claim_lintclean,lint_docspassed, 28 generated docs in sync.🤖 Generated with Claude Code