JIT: Track sideness of arrOp in GetCheckedBoundArithInfo

[EgorBo]

Fixes #100809

Minimal repro:

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);
}

It prints False in Debug and True in Release.

Here we have ((arr_len - (arr_len + -2)) >= 0) expression which should evaluate into 2 >= 0 -> true. But instead, we evaluate it as -2 >= 0 -> false. It happens because GetCheckedBoundArithInfo looses track where it took arrOp in cmpOp - from op1 or op2? the order is important since we don't guarantee that arrOper is commutative.

[dotnet-policy-service]

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

[EgorBo]

PTAL @AndyAyersMS, @dotnet/jit-contrib

Do we need to backport this to net8? The repro seems to be small, but it has to be a very specific pattern to kick in..

[AndyAyersMS]

Do we need to backport this to net8? The repro seems to be small, but it has to be a very specific pattern to kick in..

I think we should make a case for it, since it was found by one of our users.

[AndyAyersMS]

Maybe another consideration is whether this is a regression. Original issue said this does not happen in .NET 6, but I think that code pattern is fairly old. So it's worth trying your repro on .NET 7 or .NET 6 to understand what happens there.

[Ziuan]

If this is not backported to NET8, could you provide the alternative pattern that solves the issue - given the code in the original issue. The original issue uses framework calls to Array.Copy, inside which the above problem arises if I'm not mistaken.

Asking only since @AndyAyersMS mentions the pattern as being fairly old. Thanks!

[EgorBo]

So it's worth trying your repro on .NET 7 or .NET 6 to understand what happens there.

The bug was there for quite a while, it was exposed it .NET 8.0 in #81998 that introduced a VN optimization that kicks in here for (x + cns) - x. Thanks to @jakobbotsch who traced it down to that commit.
So technically, the regression is .NET 8.0 only

[EgorBo]

I'll try to backport it.

If this is not backported to NET8, could you provide the alternative pattern that solves the issue

It seems like the pattern itself is located in the standard library so it's hard to workaround it. You may try to disable <TieredPGO>false</TieredPGO> (or env var DOTNET_TieredPGO=1) that typically triggers inlining that leads to that issue.

[EgorBo]

/backport to release/8.0-staging

[github-actions]

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8653024932

[github-actions]

@EgorBo backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: Add ArrOpLHS to CompareCheckedBoundArithInfo
Using index info to reconstruct a base tree...
M	src/coreclr/jit/optcse.cpp
M	src/coreclr/jit/valuenum.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/jit/valuenum.h
Auto-merging src/coreclr/jit/optcse.cpp
CONFLICT (content): Merge conflict in src/coreclr/jit/optcse.cpp
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Add ArrOpLHS to CompareCheckedBoundArithInfo
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[github-actions]

@EgorBo an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.