Uh oh!
There was an error while loading. Please reload this page.
Fix numbering of exposed LCL_VARs - #79772
Conversation
The conservative VN must be unique for different uses lest we risk running into memory safety issues, by, e. g. removing range checks based on "racy" data.
ghost
commented
Dec 16, 2022
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsThe conservative VN must be unique for different uses lest we risk running into memory safety issues, by, e. g., removing range checks based on "racy" data. It is very easy to reproduce bad codegen with this simple method and [MethodImpl(MethodImplOptions.NoInlining)]privatestaticvoidProblem(int[]a,intb){JitUse(&b);_=a[b];_=a[b];}Assertion propagation removes the second check, which is not legal as
|
Without the fix, 4 out of 5 runs fail on my machine.
SingleAccretion
commented
Dec 17, 2022
@dotnet/jit-contrib |
aaf325e to
51a7310Comparejakobbotsch
commented
Jan 3, 2023
/azp run runtime-coreclr superpmi-asmdiffs |
|
No pipelines are associated with this pull request. |
jakobbotsch
commented
Jan 3, 2023
/azp run runtime, runtime-coreclr superpmi-diffs |
|
Azure Pipelines successfully started running 2 pipeline(s). |
jakobbotsch
commented
Jan 4, 2023
Looks like the new test needs to be disabled on wasm. |
No threading => no races.
SingleAccretion
commented
Jan 4, 2023
Looks like the test is failing on x64 under the interpreter as well. Will disable it there and create an issue once the FullAot tests are done. |
jakobbotsch
commented
Jan 11, 2023
Thanks! Let's see if this shows up in perf triage... |
AndyAyersMS
commented
Jan 11, 2023
FYI, I am seeing this new test crash on arm64 under PGO stress as part of #80481 -- suspect it's not related to that PR but haven't drilled in yet. |
SingleAccretion
commented
Jan 11, 2023
Yes, in all likelihood not related. We've now seen it fail (not crash though) on x86 too. I will put up a change to disable the test for now. |
The conservative VN must be unique for different uses lest we risk running into memory safety issues, by, e. g., removing range checks based on "racy" data.
It is very easy to reproduce bad codegen with this simple method and
JitNoCSE=1:Assertion propagation removes the second check, which is not legal as
b's value may change once we get to it from the first check.Diffs will be regressions; I see in some cases we did illegal bounds checks removal.