-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Add additional binary operations into the RangeCheck analysis. #61662
Conversation
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsChangesGT_LSH and GT_MUL are now covered in the range analysis check. This
or
Note that without this change, the previous snippet would not eliminate
as additional was implemented in the range check analysis, but multiply DiscussionI stumbled on this limitation when implementing #34938. Essentially, the strength reduction that I wrote was optimizing expressions like I have implemented Resultsaspnet.run.windows.x64.checked.mch:
Detail diffs
benchmarks.run.windows.x64.checked.mch:
Detail diffs
coreclr_tests.pmi.windows.x64.checked.mch:
Detail diffs
libraries.crossgen2.windows.x64.checked.mch:
Detail diffs
libraries.pmi.windows.x64.checked.mch:
Detail diffs
libraries_tests.pmi.windows.x64.checked.mch:
Detail diffs
|
GT_LSH and GT_MUL are now covered in the range analysis check. This allows to catch and eliminate the range check for cases like ``` ReadOnlySpan<byte> readOnlySpan => new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }; byte byt = 0; for (int i = 0; i < 5; i++) { byt = readOnlySpan[i * 3]; // ... } ``` or ``` bool[] flags = new bool[Size + 1]; for (int i = 2; i <= Size; i++) { for (int k = i * 2; k <= Size; k += i) { flags[k] = false; } } ``` Note that without this change, the previous snippet would not eliminate the range check on `flags[k]`, but the equivalent snippet would ``` for (int i = 2; i <= Size; i++) { for (int k = i + i; k <= Size; k += i) { flags[k] = false; } } ``` as additional was implemented in the range check analysis, but multiply was not.
/azp list |
Commenter does not have sufficient privileges for PR 61662 in repo dotnet/runtime |
/azp run runtime |
Commenter does not have sufficient privileges for PR 61662 in repo dotnet/runtime |
9ba6051
to
ebc2288
Compare
Tests catch some edge cases with multiplcation overflow IF the overflow detection isn't implemented correctly.
Understood. Fixed. Thank you. |
cc @dotnet/jit-contrib - is there someone familiar with range check elimination that want to give this a lookover? |
@jakobbotsch can I get an update on this? Happy to continue to make changes per review. |
@anthonycanino Sorry, this fell off my radar. @JulieLeeMSFT, do you mind assigning someone here? |
Resolved, but have not checked remaining changes
@jakobbotsch I am checking with the team. |
/azp run Fuzzlyn |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Antigen |
Azure Pipelines successfully started running 1 pipeline(s). |
Co-authored-by: Egor Bogatov <egorbo@gmail.com>
Co-authored-by: Egor Bogatov <egorbo@gmail.com>
@EgorBo @kunalspathak thanks for the extra tests. Not sure if when I comited the suggested changes it erases the results from the check list but here are the Antigen and Fuzzlyn pipeline results for quick reference. https://dev.azure.com/dnceng/public/_build/results?buildId=1498464&view=results How do I in general interpret these? Do I presume the assertion failures are related to my changes and work backwards from there? I've not not to interpret the fuzzer results yet on my other PRs. Thanks! |
I went through the results, and they seem to be existing issues, nothing specific came up for this PR. |
Hi folks, is there any further feedback or thoughts on this PR? Do we need more changes? |
@EgorBo - Can you check if this is ready to merge? |
@anthonycanino LGTM, thanks, the only note that the initial description mentions ReadOnlySpan<byte> readOnlySpan => new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
byte byt = 0;
for (int i = 0; i < 5; i++)
{
byt = readOnlySpan[i * 3];
// ...
} but I see that it's not handled currently, am I right? |
It should be handled, per the code at ebc2288#diff-44e9b099c79041ac875722c02c7de2c836313b3a22d53c91214c2a74fdeaa1cfR1003-R1018 |
@anthonycanino thank you for the contribution! |
Thanks for the review! |
Changes
GT_LSH and GT_MUL are now covered in the range analysis check. This
allows to catch and eliminate the range check for cases like
or
Note that without this change, the previous snippet would not eliminate
the range check on
flags[k]
, but the equivalent snippet wouldas additional was implemented in the range check analysis, but multiply
was not.
Discussion
I stumbled on this limitation when implementing #34938. Essentially, the strength reduction that I wrote was optimizing expressions like
arr[i + i]
toarr[i * 2]
, which would then becomearr[i << 1]
. The issue is that in some cases, this was preventing theRangeCheck
analysis from eliminating a range check, so it was a slight regression.I have implemented
GT_MUL
andGT_LSH
into the range check analysis and I am looking for some feedback, especially on whether other operations should be included in this change as well.Results
aspnet.run.windows.x64.checked.mch:
Detail diffs
benchmarks.run.windows.x64.checked.mch:
Detail diffs
coreclr_tests.pmi.windows.x64.checked.mch:
Detail diffs
libraries.crossgen2.windows.x64.checked.mch:
Detail diffs
libraries.pmi.windows.x64.checked.mch:
Detail diffs
libraries_tests.pmi.windows.x64.checked.mch:
Detail diffs