Do not mark st1 StoreSelectedScalar variant as needing consecutive registers

[kunalspathak]

In #93223, we added StoreSelectedScalar intrinsic and some of the variants of that API that takes tuple as input needs consecutive registers. However, in the hwintrinsinc table, we were falsely marking the existing API as "NeedsConsecutiveRegister". Due to this, in jitstressregs, when we limit the available registers, we were prohibiting restricting the limited registers for a definition of internal temp, but were setting limitations on the use of that internal temp.

runtime/src/coreclr/jit/lsrabuild.cpp

Lines 1883 to 1896 in 79e42f9

	if (newRefPosition->isLiveAtConsecutiveRegistersLoc(consecutiveRegistersLocation))
	{
	// If we are assigning to refPositions that has consecutive registers requirements, skip the
	// limit stress for them, because there are high chances that many registers are busy for
	// consecutive requirements and
	// we do not have enough remaining for other refpositions (like operands). Likewise, skip for the
	// definition node that comes after that, for which, all the registers are in "delayRegFree" state.
	}
	else
	#endif // TARGET_ARM64
	{
	newRefPosition->registerAssignment =
	getConstrainedRegMask(newRefPosition, oldAssignment, calleeSaveMask, minRegCountForRef);
	}

In codegen, we expect to see a single bit set for "one register" assigned to the temp, but in this case, we were assiging a different "copy" register to the use.

[000007] 20.#10 I6   Def    ORDER(A) x0   │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
         20.#11 I0   Use *  Keep     x19  │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
         20.#12 I1   Use *  Keep     d8   │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
         20.#13 I5   Use *  Keep     x20  │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
──────────────────────────────────────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
TreeID   LocRP# Name Type  Action    Reg  │x0  │x1  │x2  │x3  │x4  │x5  │x6  │x7  │x19 │x20 │x21 │d0  │d1  │d2  │d8  │d9  │
──────────────────────────────────────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
         20.#14 I6   Use *  ORDER(C) x21  │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│I6 a│    │    │    │I1 a│    │

I have fixed by introducing new intrinsic ids for various StoreSelectedScalarVectorNxM variants, similar to how we do for LoadAndInsertScalarVectorNxM APIs. For existing StoreSelectedScalar API that doesn't need consecutive registers, we now do not mark with that flag anymore.

Fixes: #95025

[ghost]

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

Issue Details

---

In #93223, we added StoreSelectedScalar intrinsic and some of the variants of that API that takes tuple as input needs consecutive registers. However, in the hwintrinsinc table, we were falsely marking the existing API as "NeedsConsecutiveRegister". Due to this, in jitstressregs, when we limit the available registers, we were prohibiting restricting the limited registers for a definition of internal temp, but were setting limitations on the use of that internal temp.

runtime/src/coreclr/jit/lsrabuild.cpp

Lines 1883 to 1896 in 79e42f9

	if (newRefPosition->isLiveAtConsecutiveRegistersLoc(consecutiveRegistersLocation))
	{
	// If we are assigning to refPositions that has consecutive registers requirements, skip the
	// limit stress for them, because there are high chances that many registers are busy for
	// consecutive requirements and
	// we do not have enough remaining for other refpositions (like operands). Likewise, skip for the
	// definition node that comes after that, for which, all the registers are in "delayRegFree" state.
	}
	else
	#endif // TARGET_ARM64
	{
	newRefPosition->registerAssignment =
	getConstrainedRegMask(newRefPosition, oldAssignment, calleeSaveMask, minRegCountForRef);
	}

In codegen, we expect to see a single bit set for "one register" assigned to the temp, but in this case, we were assiging a different "copy" register to the use.

[000007] 20.#10 I6   Def    ORDER(A) x0   │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
         20.#11 I0   Use *  Keep     x19  │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
         20.#12 I1   Use *  Keep     d8   │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
         20.#13 I5   Use *  Keep     x20  │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│    │    │    │I1 a│    │
──────────────────────────────────────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
TreeID   LocRP# Name Type  Action    Reg  │x0  │x1  │x2  │x3  │x4  │x5  │x6  │x7  │x19 │x20 │x21 │d0  │d1  │d2  │d8  │d9  │
──────────────────────────────────────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
         20.#14 I6   Use *  ORDER(C) x21  │I6 a│    │    │    │    │    │    │    │I0 a│I5 a│I6 a│    │    │    │I1 a│    │

I have fixed by introducing new intrinsic ids for various StoreSelectedScalarVectorNxM variants, similar to how we do for LoadAndInsertScalarVectorNxM APIs. For existing StoreSelectedScalar API that doesn't need consecutive registers, we now do not mark with that flag anymore.

Fixes: #95025

Author:	kunalspathak
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[kunalspathak]

@SwapnilGaikwad

[SwapnilGaikwad]

The change LGTM! Thanks for fixing it.

[kunalspathak]

@dotnet/jit-contrib