JIT: Strength reduction no longer kicks in in .NET10

[BoyBaykiller]

Previously, the input[i] was strength reduced to advance by 4 and the loop was made downwards counted; that's no longer the case, leading to worse code gen.

Windows diff (.NET9 vs .NET10): https://www.diffchecker.com/VvxRltlX/
Code in compiler explorer: https://godbolt.org/z/bbdhnP16c

public static unsafe void RadixSort(Span<int> input, Span<int> output, Vector128<float>[] mins, Vector128<float>[] maxs, int axis)
{
    const int radixSize = 11;
    const int binSize = 1 << radixSize;
    const int mask = binSize - 1;
    const int passes = 3;

    int* prefixSum = stackalloc int[binSize * passes];

    // Compute histogram for all passes
    for (int i = 0; i < input.Length; i++)
    {
        uint key = GetKey(input[i]);
        GetPrefixSumRef(key, 0)++;
        GetPrefixSumRef(key, 1)++;
        GetPrefixSumRef(key, 2)++;
    }

    ref int GetPrefixSumRef(uint key, int pass)
    {
        uint radix = (key >> (pass * radixSize)) & mask;
        ref int offset = ref prefixSum[radix + pass * binSize];

        return ref offset;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    uint GetKey(int el)
    {
        return FloatToKey(mins[el][axis] + maxs[el][axis]);
    }
}

[jakobbotsch]

Looks like a side effect of 41be5e2. We don't invert the loop anymore and strength reduction is not able to prove safety on the loop in its non-inverted state.

[BoyBaykiller]

So the actual issue is that the loop inversion heuristic doesn't consider this profitable. I see it now:

Analyzing iteration for L00 with header BB03
  Preheader = BB01
  Checking exiting block BB03
    Could not extract an IV
  Could not find any IV
Condition in block BB03 of loop L00 is a candidate for duplication to invert the loop
L00 exceeds inversion size limit of 100
L00 might benefit from cloning, but is too large to invert.

Looking at the PR, do I understand correctly that this number was tuned to be 100 mostly to prevent too much loop-cloning (and the associated size increase)? If yes: Doesn't loop-cloning, among other loop opts, have it's own heuristic do decide if its profitable. Why adjust loop-inversion heuristic to control the amount of cloning, when instead the loop-cloning heuristic itself could be changed?
I think loop-inversion itself brings a relativly small size increase, unless for already very small loops, and it enables other opts. So it seems like that should be done more aggresivly? Please let me know where I said something wrong.

[JulieLeeMSFT]

cc @jakobbotsch to respond to the question.

[AndyAyersMS]

Fixed by #129722