-
Notifications
You must be signed in to change notification settings - Fork 13.4k
PartialOrd derived for C-like enum isn't properly optimized for the <=
operator
#73338
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
LLVM can't properly optimize the match against Some(Less | Equal), if we instead match against None | Some(Greater) and negate the result, LLVM does find a way to optimize the code, because the IR we generate is somewhat simpler having to handle only one of the Some() cases. I didn't really look into how to maybe teach LLVM to handle this case, and didn't see anything obvious in the way we generate IR that could be improved here either. Should I prepare a PR to adjust the default impl of |
I wonder if this issue is related to #83623 |
We could test it in next nightly. |
Well, this issue doesn't fixed by it (which is expected because we changed MIR of && and ||, not match) so we need to make changes in LLVM or change our generated code. |
Created PR with fix. |
Upstream fix for LLVM: llvm/llvm-project@9bad7de |
…artial-eq-impl, r=Mark-Simulacrum Optimize jumps in PartialOrd le Closes rust-lang#73338 This change stops default implementation of `le()` method of PartialOrd from generating jumps.
The manual version:
The manual version ASM:
The derived version:
The derived version ASM:
The diff is that while the manual version does:
...the derived version does:
All the other
PartialOrd
operators are optimized properly.The text was updated successfully, but these errors were encountered: