JIT: avoid looking for integral ranges for non-integer constants

[AndyAyersMS]

We increasingly see constant byrefs. Make sure those don't trip up range-based optimizations.

Fixes #116861.

[Copilot]

Pull Request Overview

This PR adds an early exit in the relational comparison optimizer to skip range-based optimizations when either operand isn’t an integral type.

• Caches op1 and op2 for reuse
• Checks both operand types with varTypeIsIntegral
• Returns immediately if a non-integral type is detected

Comments suppressed due to low confidence (1)

src/coreclr/jit/morph.cpp:9071

• Consider adding unit tests to cover the new early-return path for non-integral operands (e.g., floating-point constants) to verify that the optimizer skips range logic as intended.

    if (!varTypeIsIntegral(op1->TypeGet()) || !varTypeIsIntegral(op2->TypeGet()))

[AndyAyersMS]

@EgorBo PTAL
cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[AndyAyersMS]

/azp run runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tannergooding]

The nuance between integer and byref constants seems to come up quite a bit.

I wonder if we'd have less overall problems if we had CNS_INT and CNS_REF here, so we could be more explicit about the two concepts and what is safe for each (or something like IsIntegralConst(/*allowByref*/ true) where it defaults to not including ref/byref typed integer constants.

[AndyAyersMS]

libraries-pgo failure is unrelated:

    Microsoft.Extensions.Hosting.Internal.HostTests.HostStopAsyncCanBeCancelledEarly [FAIL]
      Assert.Equal() Failure: Values differ
      Expected: Task<VoidTaskResult,<StopAsync>d__16> { Status = RanToCompletion }
      Actual:   Task { Status = RanToCompletion }

opened #117225