-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Unnecessary shr emitted for repeated multiplication #74020
Comments
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsNoted in discussion here about the recent DateTime perf optimization, that we could not rely on the JIT to safely collapse multiplication. In this example below, there's an extra shr. Same on x86. class Program
{
uint f(uint u2) {
return u2 / 2939745 / 4;
}
uint g(uint u2) {
return u2 / 11758980;
}
} Program.f(UInt32)
L0000: mov eax, edx
L0002: imul rax, 0x5b4fffcb
L0009: shr rax, 0x34
L000d: shr eax, 2
L0010: ret
Program.g(UInt32)
L0000: mov eax, edx
L0002: imul rax, 0x5b4fffcb
L0009: shr rax, 0x36
L000d: ret cc @cassioneri
|
Can repeated shr (or shl) be safely collapsed as a peephole optimization? Or are there subtleties/sideeffects that cannot be done in that way. |
Adding the Godbolt link from @cassioneri for gcc/clang: https://godbolt.org/z/T7M8Pqq1e .. MSVC seems to miss the same thing. |
Looks like a good first issue for jit first-time contributors 🙂 |
Hey, I would like to try to work with this issue. |
Noted in discussion here about the recent DateTime perf optimization, that we could not rely on the JIT to safely collapse multiplication. In this example below, there's an extra shr. Same on x86.
sharplab
cc @cassioneri
category:cq
theme:basic-cq
skill-level:beginner
cost:small
impact:small
The text was updated successfully, but these errors were encountered: