JIT: reject variable-count XOR rotation recognition

[Copilot]

When the shift count is a multiple of the operand width, both shifts yield x: XOR must return zero, whereas a rotation returns x.

// Must return zero when count is 0 or 32.
static int ShiftXor(int x, int count) =>
    (x << (count & 31)) ^ (x >>> ((32 - count) & 31));

• Recognition: Reject variable-count XOR patterns while preserving OR and constant-count XOR rotations.
• Regression coverage: Extend existing rotation tests for both directions and widths, including zero, width multiples, negative and boundary counts, and constant XOR rotations.

• Fixes JIT: (bug) XOR-based rotation recognition produces a wrong result when the shift count is a multiple of the operand width #133864

[azure-pipelines]

Azure Pipelines:
16 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.

[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.

[Copilot]

🟢 Approval recommended

The fix and regression coverage address the reported JIT miscompile.

Pull request overview

Fixes a RyuJIT miscompile by rejecting variable-count XOR patterns as rotations.

Changes:

• Restricts XOR rotation recognition to valid constant-count patterns.
• Adds regression coverage for widths, directions, boundaries, and constant rotations.

File summaries

File	Description
src/coreclr/jit/morph.cpp	Prevents invalid variable-count XOR-to-rotation transformations.
src/tests/JIT/CodeGenBringUpTests/Rotate.cs	Adds regression tests for XOR rotation edge cases.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

[EgorBo]

PTAL @dhartglassMSFT

[tannergooding]

LGTM. That being said, the rotation recognition logic here is "very complex" for something where ideally most users would just use int.RotateLeft or similar.

We also support "basically any pattern" that resembles a rotation, rather than pushing users towards a single standard pattern.

I think it'd be worth simplifying this in .NET 12 and telling users to fix their code or use the dedicated helpers. We really don't need this to handle every scenario possible or be this complex.