JIT: fix byte range used by RangeCheck

[AndyAyersMS]

Fix wrong byte range introduced in #21857.

Thanks to @jakobbotsch for spotting this.

[AndyAyersMS]

cc @dotnet/jit-contrib

No diffs in pmi fx.

[hughbe]

Just curious and for a bunch of small jit fixes, why do they not have tests? I get slightly confused when code changes occur without tests? In llvm, for example, all small changes verify actual asm output (obviously too much in clr) but does the type of testing in coreclr need to be improved?

[BruceForstall]

@hughbe It's generally a good idea to add tests, when possible. If @AndyAyersMS can come up with a test exhibiting a difference here, that would be great. Sometimes it's too expensive or not feasible.

[AndyAyersMS]

I'll see if I can come up with something, though the most likely impact is a missed optimization, and we don't have a great testing strategy for those.

[filipnavara]

Looks like in this case you may end-up with missing bounds check in extreme case. That probably should be testable. Feel free to correct me if I am wrong.

I am thinking of pseudo code akin to this:

Array data = Array.CreateInstance(typeof(int),
    new int[] { -127, 256 });
byte index = -128;
data[index] = 0; // Range check would be incorrectly omitted and memory accessed out of range

[AndyAyersMS]

I have something similar in the works, will push it on this PR shortly. RangeCheck doesn't model a lot of IR operators so you have to be careful to choose just the right expressions.

[AndyAyersMS]

Test covers some of the byte/sbyte boundaries, and will fail without this fix.