JIT: support TYP_LONG induction variables in loop analysis and cloning

[AndyAyersMS]

AnalyzeIteration and the loop cloner now recognize long IVs end-to-end, covering loop limits like long params, arr.Length, and arr.LongLength (the bounds-check length is widened via a non-overflowing cast as needed). A new LoopsWithLongIV metric reports how often the analysis fires.

[dotnet-policy-service]

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

[AndyAyersMS]

@tannergooding FYI

Local runs show no new cloning in SPMI, all long-IV controlled loops seen are pointer math so no bounds check removal opportunities to inspire cloning.

However we might consider taking this regardless, just for future-proofing.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop iteration analysis and loop cloning to recognize and carry TYP_LONG induction variables through more of the pipeline, and adds a new JIT metadata metric to track when long-IV iteration analysis succeeds.

Changes:

• Extend loop iteration analysis (and related consumers) to accept TYP_LONG IVs, including limit/offset handling and cast “peeling” for widened limits.
• Update loop cloning symbolic identifiers/conditions to support long-typed constants/offsets and to widen int-vs-long comparisons.
• Add a LoopsWithLongIV JIT metadata metric.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/coreclr/jit/optimizer.cpp	Loosens IV increment-constant recognition and blocks unrolling for non-TYP_INT IVs.
src/coreclr/jit/loopcloning.h	Expands loop-cloning symbolic identifier representation to carry long constants/offsets.
src/coreclr/jit/loopcloning.cpp	Emits long constants/offsets in generated trees and widens int/long compare operands for cloning conditions; adds long-IV metric increment.
src/coreclr/jit/jitmetadatalist.h	Adds LoopsWithLongIV metric to the metadata metric list.
src/coreclr/jit/flowgraph.cpp	Extends AnalyzeIteration limit/init recognition to handle TYP_LONG, including peeling casts/offsets and evaluating trivial base cases for long.
src/coreclr/jit/compiler.h	Updates NaturalLoopIterInfo to store constants/offsets as pointer-sized integers and exposes them via updated signatures.

Comments suppressed due to low confidence (1)

src/coreclr/jit/compiler.h:1975

• NaturalLoopIterInfo now stores IV constants/offsets in ssize_t (ConstInitValue, LimitOffset) and exposes them via ssize_t IterConst()/ConstLimit(). ssize_t is pointer-sized, so on 32-bit builds it cannot represent full 64-bit TYP_LONG IV values (genTypeSize(TYP_LONG)==8) and will truncate long IV constants/offsets. These fields/return types should use an explicit 64-bit type (e.g. int64_t) for TYP_LONG support rather than ssize_t.

    // Constant value that the induction variable is initialized with, outside
    // the loop. Only valid if HasConstInit is true. Width matches the IV
    // (TYP_INT IV: int-sized; TYP_LONG IV: long-sized).
    ssize_t ConstInitValue = 0;

    // Tree that has the loop test for the induction variable.
    GenTree* TestTree = nullptr;

    // Block that has the loop test.
    BasicBlock* TestBlock = nullptr;

    // Tree that mutates the induction variable.
    GenTree* IterTree = nullptr;

[tannergooding]

Local runs show no new cloning in SPMI, all long-IV controlled loops seen are pointer math so no bounds check removal opportunities to inspire cloning.

I wonder how much of this is limited because we don't recognize the loop limit as being special....

One scenario that I see is typically something like the below, where they arrays can index directly and spans often use Unsafe.Add due to lack of an nint based indexer:

int sum = 0;

// similar for span, but there is no `nint` indexer, so devs either use `Unsafe.Add` or cast back to `int`
for (nint i = 0; i < array.Length; i++)
{
    sum += array[i];
}

return sum;

But the other case is how TensorSpan works, where a user has defined effectively their own span type. A minimal repro would be the below struct, and then a loop similar to the above. We have similar logic all over for TensorSpan since we need to support more than int.MaxValue elements:

public ref struct CustomSpan<T>
{
    private readonly ref T _reference;
    private readonly nint _length;

    public nint Length => _length;

    public ref T this[nint index]
    {
        get
        {
            // Type invariant is that `_length` is never negative, the JIT specially handles this for `System.Span` but we can't relay that for our custom type
            if ((nuint)(index) >= (nuint)(_length))
            {
                ThrowIndexOutOfRangeException();
            }
            return ref Unsafe.Add(ref _reference, index);
        }
    }
}

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 10 comments.

Comments suppressed due to low confidence (1)

src/coreclr/jit/flowgraph.cpp:5901

• MatchLimit uses limitOp->IsCnsIntOrI() to recognize constant limits, but that only matches GT_CNS_INT. For long-IV loops on 32-bit targets, constant limits may be GT_CNS_LNG, so the loop won't be recognized. Consider using limitOp->IsIntegralConst() (and ensure downstream ConstLimit() uses IntConCommon APIs).

    // Check what type of limit we have - constant, variable or arr-len.
    if (limitOp->IsCnsIntOrI())
    {
        info->HasConstLimit = true;
        if ((limitOp->gtFlags & GTF_ICON_SIMD_COUNT) != 0)

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.