Fix for arm64 outerloop jitstress failures in FMA

[dhartglassMSFT]

Previous codegen for FMLA, when supplied with a non-constant operand, looked something like:

mov     v0.8b, v8.8b // fill in RMW operand
br      x20
fmla    v0.2s, v9.2s, v10.s[0]
b       G_M19624_IG23
fmla    v0.2s, v9.2s, v10.s[1]
b       G_M19624_IG23
// and so on for each of the immediates

With the recent refactor to move the mov-emit-for-RMW down into the emit routines, the mov is emitted instead when codegen happens for each arm of the jump table:

br      x20
mov     v0.8b, v8.8b                    // fill in RMW operand
fmla    v0.2s, v9.2s, v10.s[0]
b       G_M19624_IG24
mov     v0.8b, v8.8b                   // fill in RMW operand
fmla    v0.2s, v9.2s, v10.s[1]
b       G_M19624_IG24
// etc...

Bug happens because the jump table builder thought each case would contain only 1 instruction, not two.

@a74nh Another option to fix this is to undo the refactor just for this case, and not duplicate the mov in each branch. This would yield slightly smaller codesize. I think it shouldn't matter much overall because the size difference is small, and the non-constant-operand case is rare. Let me know if we should go this route instead

fixes #126379

[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

Fixes ARM64 JIT codegen for certain HWIntrinsics that use a non-constant immediate (requiring a jump table) and have RMW semantics (or otherwise emit an extra mov), ensuring the jump table entry-size calculation matches the actual number of emitted instructions.

Changes:

• Pass an explicit numInstrs to HWIntrinsicImmOpHelper for RMW SIMDByIndexedElement (4-operand) and RMW shift-by-immediate intrinsics to account for the extra mov that may be emitted.
• Add debug assertions that the 2-operand and 3-operand SIMDByIndexedElement immediate cases are not treated as RMW.

[a74nh]

@a74nh Another option to fix this is to undo the refactor just for this case, and not duplicate the mov in each branch. This would yield slightly smaller codesize. I think it shouldn't matter much overall because the size difference is small, and the non-constant-operand case is rare. Let me know if we should go this route instead

As long as we don't change the code in the emitter, then I'm happy.

If you undid the code in these two codegen functions, then there would be a mov added if required, and then the call to the emitter would be
emitIns_R_R_R_R_I(ins, emitSize, targetReg, targetReg, op2Reg, op3Reg, elementIndex, opt);
which means the emitter wouldn't emit a movprfx.

I'm happy with doing it that way.

Yes, it's only two functions (and they can't get inlined), but we should set a precedence if we need more in the future.

[dhartglassMSFT]

/azp run runtime-coreclr jitstress2-jitstressregs

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dhartglassMSFT]

jitstress regs failures are infrastructure failures

osx-arm64 stress passed, at least