Simplify discriminant codegen for niche-encoded variants which don't wrap across an integer boundary#143784
Merged
bors merged 3 commits intorust-lang:masterfrom Jul 19, 2025
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Inspired by #139729, this attempts to be a much-simpler and more-localized change while still making a difference. (Specifically, this does not try to solve the problem with select-sinking, leaving that to be fixed by llvm/llvm-project#134024 -- once it gets released -- instead of in rustc's codegen.)
What this does improve is checking for the variant in a 3+ variant enum when that variant is the type providing the niche. Something like
if let Foo::WithBool(_) = ...previously compiled tougt(add(x, -2), 2), which is non-trivial to think about because it's depending on the unsigned wrapping to shift the 0/1 up above 2. With this PR it compiles to justult(x, 2), which is probably what you'd have written yourself if you were doing it by hand to look for "is this byte a bool?".That's done by leaving most of the codegen alone, but adding a couple new special cases to the
is_nichecheck. The default looks at the relative discriminant, but in the common cases where there's no wraparound involved, we can just check the original value, rather than the offsetted one.The first commit just adds some tests, so the best way to see the effect of this change is to look at the second commit and how it updates the test expectations.