Fix a couple issues with Vector.WithElement

[tannergooding]

Resolves #115532
Resolves #115487
Resolves #115459
Resolves #115644

These were introduced with #115348

[Copilot]

Pull Request Overview

This PR fixes issues with the Vector.WithElement intrinsic functionality and addresses related JIT failures by updating test cases and modifying the lowering and code generation logic.

• Updates test projects for runtime verification of the intrinsic changes.
• Revises the index calculation and bounds handling in the JIT lowering logic.
• Adjusts the emitter call in the hardware intrinsic code generation.

Reviewed Changes

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

Show a summary per file

File	Description
src/tests/JIT/Regression/JitBlue/Runtime_115532/Runtime_115532.csproj	New project file for test verification
src/tests/JIT/Regression/JitBlue/Runtime_115532/Runtime_115532.cs	Test verifying the Vector.WithElement behavior
src/tests/JIT/Regression/JitBlue/Runtime_115487/Runtime_115487.csproj	New project file for test verification
src/tests/JIT/Regression/JitBlue/Runtime_115487/Runtime_115487.cs	Test demonstrating proper intrinsic handling and JIT behavior
src/coreclr/jit/lowerxarch.cpp	Refactored index handling with modulo masking and refined assert condition
src/coreclr/jit/hwintrinsiccodegenxarch.cpp	Changed emitter instruction from ins_Move_Extend to ins_Store to reflect desired semantics

Comments suppressed due to low confidence (2)

src/coreclr/jit/lowerxarch.cpp:5676

• [nitpick] Using modulo to constrain 'imm8' limits the index into the SIMD vector, which may hide unexpected negative values from upstream logic. Please confirm that this behavior is intended and consider adding a comment that documents the rationale behind the modulo operation.

ssize_t imm8      = static_cast<uint8_t>(op2->AsIntCon()->IconValue()) % count;

src/coreclr/jit/hwintrinsiccodegenxarch.cpp:2008

• The instruction call has been updated from ins_Move_Extend to ins_Store. Please verify that this change is aligned with the intended store semantics and add documentation if necessary to clarify the rationale for future maintainers.

GetEmitter()->emitIns_ARX_R(ins_Store(op3->TypeGet()),        // Store

[filipnavara]

Alternative to #115645?

[dotnet-policy-service]

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

[tannergooding]

Alternative to #115645?

Yes. One that fixes the issues as they were relatively small/simple

[kunalspathak]

LGTM

[tannergooding]

Looks like Mono currently asserts for these:

16:52:47.954 Running test: JIT/Regression/JitBlue/Runtime_115532/Runtime_115532/Runtime_115532.dll
* Assertion at /Users/runner/work/1/s/src/mono/mono/mini/mini-amd64.c:7783, condition `ins->inst_c0 == 1' not met

This should be a relatively simple thing to handle and I'll take a look. CC. @lewing since you've done several of the recent Mono SIMD PRs

[tannergooding]

CC. @jakobbotsch; could I get a second pair of eyes over this.

Should have everything handled now and working with the change.

[tannergooding]

/azp run runtime-coreclr jitstress-isas-x86, Fuzzlyn, Antigen, runtime-coreclr jitstress, runtime-coreclr jitstressregs

[azure-pipelines]

Azure Pipelines successfully started running 5 pipeline(s).

[tannergooding]

runtime-coreclr jitstress and runtime-coreclr jitstressregs is an unrelated timeout in JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b425314/b425314/b425314

Fuzzlyn is #115109, an unrelated issue around do-while loops

[tannergooding]

/b-ag unrelated outerloop timeouts in the non-default runtime-llvm job

[tannergooding]

/ba-g unrelated outerloop timeouts in the non-default runtime-llvm job

[kendall1997]

Hi @tannergooding, sorry for the inconvenience of the original PR, thanks for taking care of the issues quickly.