-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pattern matching on enum creates unecessary jump table #115742
Comments
@rustbot label I-slow |
Looking at the IR form https://godbolt.org/z/G79jaedqa, I believe this is a duplicate issue of #113506. @rustbot claim |
The ordering of the variant payloads is not guaranteed to be in source order for |
But in this case rustc did decide to put it at the same offset for each variant, so no jump table should be needed |
Not fixed by the LLVM 18 upgrade. Keeping the label though, as LLVM 19 should fix this thanks to getelementptr i8 canonicalization. |
Fixed in nightly by #121665: https://godbolt.org/z/rPhrxTq61 I don't think this needs a test, since |
Yes. InstCombine now do this transformation. It's different from #113506. |
Closing as per #115742 (comment) |
I tried this code:
Say we define an AST type for expressions, each carrying a span to give its position in the original source code:
I expected to see this happen:
The
ByteSpan
is placed at the same offset for every variant of the enum, so the final assembly forspan
should be:Instead, this happened:
A jump table is generated, even though every entry in the jump table is identical (godbolt):
If the last 2 variants are removed, the optimal code is produced. If only the last variant is removed, the code is better, but still suboptimal:
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: