SVE: movprfx logic should be as centralized as possible

[kunalspathak]

There are lot of places where we check for if (targetReg != op1Reg) then generate movprfx. This should be centralized so we do not accidently miss adding it.

Reference: #115428 (comment)

[kunalspathak]

@dotnet/arm64-contrib

[dotnet-policy-service]

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

[a74nh]

Today for generic handling of a 2 op instruction, in hwintrinsiccodegenarm64.cpp:

                    else if (isRMW)
                    {
                        assert((targetReg == op1Reg) || (targetReg != op2Reg));
                        GetEmitter()->emitIns_Mov(INS_mov, emitTypeSize(node), targetReg, op1Reg,
                                                  /* canSkip */ true);
                        GetEmitter()->emitIns_R_R(ins, emitSize, targetReg, op2Reg, opt);
                    }
                    else
                    {
                        GetEmitter()->emitIns_R_R_R(ins, emitSize, targetReg, op1Reg, op2Reg, opt);
                    }

(note when ins is an SVE instruction, the emitIns_Mov, should ideally be emitting a movprfx, but this will always emit a NEON mov)

And similar for instructions with special codegen:

            case NI_Sve2_BitwiseSelect:
            case NI_Sve2_BitwiseSelectLeftInverted:
            case NI_Sve2_BitwiseSelectRightInverted:
                // op1: select, op2: left, op3: right
                // Operation is destructive on the 'left' operand.
                if (targetReg != op2Reg)
                {
                    assert(targetReg != op3Reg && targetReg != op1Reg);
                    GetEmitter()->emitInsSve_R_R(INS_sve_movprfx, EA_SCALABLE, targetReg, op2Reg);
                }
                // Always use the lane size D. It's a bitwise operation so this is fine for all integer vector types.
                GetEmitter()->emitInsSve_R_R_R(ins, emitSize, targetReg, op3Reg, op1Reg, INS_OPTS_SCALABLE_D);
                break;

This becomes more complicated when using an operation embedded in a conditional select (see else if (intrin.numOperands >= 2 && intrin.op2->IsEmbMaskOp()) - ideally this block should be a new function). There is a lot of code here to handle all the different embedded cases. Hidden inside here is a lot of movprfx uses. Some of these uses are hints for the CPU to optimise destructive uses. There are also cases where we emit a sel before the instruction instead of a movprfx.

---

The proposal is that in the first example the code should just be:

                    else
                    {
                        GetEmitter()->emitIns_R_R_R(ins, emitSize, targetReg, op1Reg, op2Reg, opt);
                    }

Then inside emitIns_R_R_R(), it will do:

                    if (isRMW)
                    {
                        assert((targetReg == op1Reg) || (targetReg != op2Reg));
                        GetEmitter()->emitIns_Mov(INS_mov, emitTypeSize(node), targetReg, op1Reg,
                                                  /* canSkip */ true);
                        GetEmitter()->emitIns_R_R(ins, emitSize, targetReg, op2Reg, opt);
                         return
                    }

The problem is at this level there is not simple isRMW check available. So that if would need to be a switch on all valid rmw instructions that could pass through here.

Also, make sure to emit a movprfx instead of mov when it's an SVE instruction.

Given there is already a switch in these functions, the new switch should be combined into that.

In additional, the destructive movprfx use hints (which are only done for operations embedded in a conditional select) should probably be cleaned up in a similar way, depending whether we have enough information inside the emit function to make that decision. That should be left for a separate PR, and should take into account #107134

Once done, then "just" remove all the relevant mov/movprfx uses in hwintrinsiccodegenarm64.cpp.

---

Seems reasonable, but there are a lot of instructions. The number of intrinsics marked as RMW are:
hwintrinsiclistarm64.h:109
hwintrinsiclistarm64sve.h:111

These will mostly map 1:1 to an instruction.
All of those will need modifications in the emit functions.