JIT: include element info when comparing array address trees

[AndyAyersMS]

GenTree::Compare ignored the element size on GT_ARR_ELEM and all of the element metadata on GT_ARR_ADDR and GT_INDEX_ADDR, so tail merge could fold two array element addresses that differ only in element type or scale. Also hash these fields, and move the unreachable GT_INDEX_ADDR case in gtHashValue to the binop arm where it can actually run.

Fixes #131459.

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

No diffs expected.

[azure-pipelines]

Azure Pipelines:
Successfully started running 5 pipeline(s).
11 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR fixes a JIT correctness issue where GenTree::Compare (and related hashing) did not include key element metadata for array-address-related nodes, allowing tail-merge/CSE to incorrectly treat distinct array element address computations as identical. It also adds a JIT regression test covering the reported miscompile and a related GT_ARR_ADDR metadata scenario.

Changes:

• Extend GenTree::Compare to include element metadata when comparing GT_ARR_ELEM, GT_ARR_ADDR, and GT_INDEX_ADDR.
• Extend Compiler::gtHashValue to hash the same element metadata for GT_ARR_ELEM, GT_ARR_ADDR, and GT_INDEX_ADDR (and move GT_INDEX_ADDR hashing to the correct operator-kind arm).
• Add a regression test (Runtime_131459) and include it in Regression_ro_2.csproj.

Reviewed changes

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

File	Description
src/coreclr/jit/gentree.cpp	Include array element/type/scale metadata in GenTree::Compare and gtHashValue for relevant tree kinds to prevent incorrect folding/merging.
src/tests/JIT/Regression/JitBlue/Runtime_131459/Runtime_131459.cs	Add regression coverage for GT_ARR_ELEM element-size compare and GT_ARR_ADDR element-type/class-handle metadata compare.
src/tests/JIT/Regression/Regression_ro_2.csproj	Add the new regression test file to the compilation list.

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (3)

src/coreclr/jit/gentree.cpp:3624

• Similarly, in the binary ExOp arm of gtHashValue, the comment "For the ones below no extra argument matters for comparison." is no longer accurate now that GT_INDEX_ADDR hashes multiple metadata fields. Please update the comment to reflect the new structure.
  src/tests/JIT/Regression/JitBlue/Runtime_131459/Runtime_131459.cs:56
• The AddressBig coverage looks ineffective for this fix: S256/S512 have element sizes 256/512, but the JIT importer rejects expanding mdarray intrinsics when arrayElemSize doesn’t fit in unsigned char (see src/coreclr/jit/importercalls.cpp around the FitsIn<unsigned char>(arrayElemSize) check). That means these cases likely won’t produce GT_ARR_ELEM, so they won’t exercise the new GenTree::Compare/gtHashValue element-size handling. Consider removing this section or changing the types to sizes <= 255 so it stays on the intrinsic/GT_ARR_ELEM path.

    [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
    private static ref byte AddressBig(bool small, object array)
    {
        if (small)
        {

src/coreclr/jit/gentree.cpp:3569

• In gtHashValue, the comment "For the ones below no extra argument matters for comparison." is now misleading because GT_ARR_ADDR immediately below does contribute additional metadata to the hash. Updating the comment avoids future confusion when adding more ExOp cases.

This issue also appears on line 3621 of the same file.