[release/8.0-staging] JIT: Track sideness of arrOp in GetCheckedBoundArithInfo

[EgorBo]

Fixes #100809

Backport of #100848 to release/8.0-staging

Customer Impact

• Customer reported
• Found internally

Reported in #100809, there is a very specific pattern that is incorrectly lowered by JIT into an invalid code. Unfortunately, there is no good workaround for it we can recommend + the pattern in question lives in the BCL so users can't change it. The minimal repro to hit the bug is:

using System.Runtime.CompilerServices;

AlwaysFalse(10);

[MethodImpl(MethodImplOptions.NoInlining | 
            MethodImplOptions.AggressiveOptimization)]
bool AlwaysFalse(int x)
{
    var result = new byte[x];
    int count = result.Length - 2;
    return (x < 0 || result.Length - count < 0);
}

Prints True in Release and False in Debug. The actual bug was introduced many releases ago, but it started to manifest only since .NET 8.0 because of an unrelated optimization (#81998) that exposed it.
 

Regression

• Yes
• No

Regressed in .NET 8.0

Testing

Added a test

Risk

Low: it requires a very specific code pattern to hit

[dotnet-policy-service]

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

[jakobbotsch]

What about the other uses of this function? Do they need to be changed too?

[EgorBo]

@jakobbotsch I've inspected all uses and didn't find places where we might make wrong decisions due to order of operands (the only use of arrOp is this CSE where we compose a new VN and in rangecheck)

[EgorBo]

PTAL @AndyAyersMS @jakobbotsch (backport of #100848)

[jeffschwMSFT]

lgtm. we will take for consideration in 8.0.x