Repository navigation
[llvm] Drop four LLVM tuning knobs that never reached codegen - #1153
Merged
Merged
Conversation
coderfeli
reviewed
Sep 18, 2026
coderfeli
reviewed
Sep 18, 2026
Phil-amd
force-pushed
the
phil/drop-inert-llvm-knobs
branch
2 times, most recently
from
September 18, 2026 06:16
4f572fd to
a14afdf
Compare
Collaborator
|
minor documentation follow-up: base.py and kernel_function.py still describe |
Phil-amd
force-pushed
the
phil/drop-inert-llvm-knobs
branch
from
September 18, 2026 08:00
a14afdf to
be7c643
Compare
Member
Author
|
Done — fixed in be7c643:
|
`gpu-module-to-binary{opts=...}` is never read on AMD: tokenizeCmdOptions()
has only XeVM and NVVM callers, and assembleIsa() takes no flags parameter.
The two flags routed through it were never flags anyway -- amdgpu-waves-per-eu
and amdgpu-num-vgpr are IR function attributes, which llc rejects. waves_per_eu
survives only because lower_compile_hints also sets the rocdl attribute.
maxnreg had no such path and stayed inert while autotune searched over it, so
it now raises; Config(maxnreg=...) raises too, since **kwargs would otherwise
swallow it as a Constexpr arg. Caches written earlier still load -- the stale
key is dropped, not rejected. Also drop amdgpu-schedule-regions (not a cl::opt
in the pin), expert-scheduling-mode on gfx942 (gated GFX12+, and toggling it
leaves gfx942/gfx950 byte-identical while changing gfx1250 visibly), and fix
the FLYDSL_LLVM_ENABLE_POST_MISChed casing typo. bin_cli_opts is left empty
with a comment, so nothing is routed through the dead lane again.
None was harmless: an unknown hint still changes the JIT cache key, so each
produced a real recompile that behaved exactly like setting nothing.
Phil-amd
force-pushed
the
phil/drop-inert-llvm-knobs
branch
from
September 18, 2026 08:08
be7c643 to
acf5331
Compare
Member
Author
|
Folded the documentation mentions into this PR as well (acf5331), so
Now 11 files. Style gate and |
coderfeli
approved these changes
Sep 20, 2026
Phil-amd
added a commit
that referenced
this pull request
Sep 20, 2026
Nothing in the tree could answer "which LLVM knob do I turn, and did it apply?" -- a grep of all 17 SKILL.md files finds no -mllvm, llc, opt or mlir-opt recipe anywhere. That gap is what let the four inert knobs removed in #1153 sit there unnoticed: a knob that silently does nothing looks exactly like one that works: an unknown hint still forces a recompile. So the skill leads with verification, not with the knob list. Every recipe pairs an artifact grep with a mandatory negative control: misspell the key, and the assertion must fail; if it still passes, the instrument is dead. Ships per-arch references for gfx950 and gfx1250, whose occupancy knobs are not interchangeable, and two scripts proven against both controls. Cross-references added to the four sibling skills that lead here; nothing discovers a skill automatically. flydsl-kernel-authoring also had two mis-attributions about the dead opts= lane, corrected in passing.
Phil-amd
added a commit
that referenced
this pull request
Sep 20, 2026
Nothing in the tree could answer "which LLVM knob do I turn, and did it apply?" -- a grep of all 17 SKILL.md files finds no -mllvm, llc, opt or mlir-opt recipe anywhere. That gap is what let the four inert knobs removed in #1153 sit there unnoticed: a knob that silently does nothing looks exactly like one that works, since an unknown hint still forces a recompile. So the skill leads with verification, not with the knob list. Every recipe pairs an artifact grep with a mandatory negative control: misspell the key, and the assertion must fail; if it still passes, the instrument is dead. Ships per-arch references for gfx950 and gfx1250, whose occupancy knobs are not interchangeable, and two scripts proven against both controls. Cross-references added to the four sibling skills that lead here; nothing discovers a skill automatically. flydsl-kernel-authoring also had two mis-attributions about the dead opts= lane, corrected in passing.
Phil-amd
added a commit
that referenced
this pull request
Sep 20, 2026
Nothing in the tree could answer "which LLVM knob do I turn, and did it apply?" -- a grep of all 17 SKILL.md files finds no -mllvm, llc, opt or mlir-opt recipe anywhere. That gap is what let the four inert knobs removed in #1153 sit there unnoticed: a knob that silently does nothing looks exactly like one that works, since an unknown hint still forces a recompile. So the skill leads with verification, not with the knob list. Every recipe pairs an artifact grep with a mandatory negative control: misspell the key, and the assertion must fail; if it still passes, the instrument is dead. Ships per-arch references for gfx950 and gfx1250, whose occupancy knobs are not interchangeable, and two scripts proven against both controls. Cross-references added to the four sibling skills that lead here; nothing discovers a skill automatically. flydsl-kernel-authoring also had two mis-attributions about the dead opts= lane, corrected in passing.
Phil-amd
added a commit
that referenced
this pull request
Sep 20, 2026
Nothing in the tree could answer "which LLVM knob do I turn, and did it apply?" -- a grep of all 17 SKILL.md files finds no -mllvm, llc, opt or mlir-opt recipe anywhere. That gap is what let the four inert knobs removed in #1153 sit there unnoticed: a knob that silently does nothing looks exactly like one that works, since an unknown hint still forces a recompile. So the skill leads with verification, not with the knob list. Every recipe pairs an artifact grep with a mandatory negative control: misspell the key, and the assertion must fail; if it still passes, the instrument is dead. Ships per-arch references for gfx950 and gfx1250, whose occupancy knobs are not interchangeable, and two scripts proven against both controls. Cross-references added to the four sibling skills that lead here; nothing discovers a skill automatically. flydsl-kernel-authoring also had two mis-attributions about the dead opts= lane, corrected in passing.
Phil-amd
added a commit
that referenced
this pull request
Sep 20, 2026
Nothing in the tree could answer "which LLVM knob do I turn, and did it apply?" -- a grep of all 17 SKILL.md files finds no -mllvm, llc, opt or mlir-opt recipe anywhere. That gap is what let the four inert knobs removed in #1153 sit there unnoticed: a knob that silently does nothing looks exactly like one that works, since an unknown hint still forces a recompile. So the skill leads with verification, not with the knob list. Every recipe pairs an artifact grep with a mandatory negative control: misspell the key, and the assertion must fail; if it still passes, the instrument is dead. Ships per-arch references for gfx950 and gfx1250, whose occupancy knobs are not interchangeable, and two scripts proven against both controls. Cross-references added to the four sibling skills that lead here; nothing discovers a skill automatically. flydsl-kernel-authoring also had two mis-attributions about the dead opts= lane, corrected in passing.
Phil-amd
added a commit
that referenced
this pull request
Sep 21, 2026
Nothing in the tree could answer "which LLVM knob do I turn, and did it apply?" -- a grep of all 17 SKILL.md files finds no -mllvm, llc, opt or mlir-opt recipe anywhere. That gap is what let the four inert knobs removed in #1153 sit there unnoticed: a knob that silently does nothing looks exactly like one that works, since an unknown hint still forces a recompile. So the skill leads with verification, not with the knob list. Every recipe pairs an artifact grep with a mandatory negative control: misspell the key, and the assertion must fail; if it still passes, the instrument is dead. Ships per-arch references for gfx950 and gfx1250, whose occupancy knobs are not interchangeable, and two scripts proven against both controls. Cross-references added to the four sibling skills that lead here; nothing discovers a skill automatically. flydsl-kernel-authoring also had two mis-attributions about the dead opts= lane, corrected in passing.
coderfeli
pushed a commit
that referenced
this pull request
Sep 22, 2026
Nothing in the tree could answer "which LLVM knob do I turn, and did it apply?" -- a grep of all 17 SKILL.md files finds no -mllvm, llc, opt or mlir-opt recipe anywhere. That gap is what let the four inert knobs removed in #1153 sit there unnoticed: a knob that silently does nothing looks exactly like one that works, since an unknown hint still forces a recompile. So the skill leads with verification, not with the knob list. Every recipe pairs an artifact grep with a mandatory negative control: misspell the key, and the assertion must fail; if it still passes, the instrument is dead. Ships per-arch references for gfx950 and gfx1250, whose occupancy knobs are not interchangeable, and two scripts proven against both controls. Cross-references added to the four sibling skills that lead here; nothing discovers a skill automatically. flydsl-kernel-authoring also had two mis-attributions about the dead opts= lane, corrected in passing.
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
3 participants
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.
What
Four LLVM tuning knobs in this tree never reached codegen. Removes them.
Why they did nothing
gpu-module-to-binary{opts=...}is never read on AMD:tokenizeCmdOptions()has only XeVM and NVVM callers, and
assembleIsa()takes no flags parameter.The two flags routed through it were never flags anyway --
amdgpu-waves-per-euand
amdgpu-num-vgprare IR function attributes, whichllcrejects.waves_per_eusurvives only becauselower_compile_hintsalso sets the rocdlattribute.
maxnregautotune.Configsearched over itamdgpu-schedule-regionsllcrejects itamdgpu-expert-scheduling-modeon gfx942getGeneration() >= GFX12FLYDSL_LLVM_ENABLE_POST_MISChedNone was harmless: an unknown hint still changes the JIT cache key, so each
produced a real recompile that behaved exactly like setting nothing.
⚠ Behaviour change: the
maxnreghint now raisesValueErrorandConfig(maxnreg=...)raisesTypeError--**kwargswould otherwise swallowit as a Constexpr arg. Use
waves_per_eu. Autotune caches written earlier stillload; the stale key is dropped, not rejected.
Testing
Every claim verified against the pinned LLVM (
e2a39f504), each with a positivecontrol established before any negative was recorded. gfx942
expert-scheduling-modeis the example: toggling it leaves gfx942/gfx950byte-identical while changing gfx1250 visibly, so the instrument reads and the
gfx942 result is a real negative. Config unit tests pass; ruff and black clean.