Fix numbering of exposed LCL_VARs

[SingleAccretion]

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:

[MethodImpl(MethodImplOptions.NoInlining)]
private static int Problem(int[] a, int b)
{
    JitUse(&b);
    return a[b] + a[b];
}

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.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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:

[MethodImpl(MethodImplOptions.NoInlining)]
private static void Problem(int[] a, int b)
{
    JitUse(&b);
    _ = a[b];
    _ = a[b];
}

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.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[SingleAccretion]

@dotnet/jit-contrib

[jakobbotsch]

/azp run runtime-coreclr superpmi-asmdiffs

[azure-pipelines]

No pipelines are associated with this pull request.

[jakobbotsch]

/azp run runtime, runtime-coreclr superpmi-diffs

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jakobbotsch]

Looks like the new test needs to be disabled on wasm.

[SingleAccretion]

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]

Thanks! Let's see if this shows up in perf triage...

[AndyAyersMS]

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.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=133883&view=ms.vss-test-web.build-test-results-tab

[SingleAccretion]

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.