-
Notifications
You must be signed in to change notification settings - Fork 13.3k
PartialOrd derived for C-like enum isn't properly optimized for the <=
operator
#73338
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
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: