Updating emitInsCanOnlyWriteSSE2OrAVXReg to cover some of the newer instructions.

[tannergooding]

Resolves https://github.com/dotnet/coreclr/issues/19127, https://github.com/dotnet/coreclr/issues/18997, and part of https://github.com/dotnet/coreclr/issues/19008.

[tannergooding]

Rebased onto head now that #19130 has been merged.

[tannergooding]

@dotnet-bot test Windows_NT x64 Checked jitincompletehwintrinsic
@dotnet-bot test Windows_NT x64 Checked jitx86hwintrinsicnoavx
@dotnet-bot test Windows_NT x64 Checked jitx86hwintrinsicnoavx2
@dotnet-bot test Windows_NT x64 Checked jitx86hwintrinsicnosimd
@dotnet-bot test Windows_NT x64 Checked jitnox86hwintrinsic

@dotnet-bot test Windows_NT x86 Checked jitincompletehwintrinsic
@dotnet-bot test Windows_NT x86 Checked jitx86hwintrinsicnoavx
@dotnet-bot test Windows_NT x86 Checked jitx86hwintrinsicnoavx2
@dotnet-bot test Windows_NT x86 Checked jitx86hwintrinsicnosimd
@dotnet-bot test Windows_NT x86 Checked jitnox86hwintrinsic

@dotnet-bot test Ubuntu x64 Checked jitincompletehwintrinsic
@dotnet-bot test Ubuntu x64 Checked jitx86hwintrinsicnoavx
@dotnet-bot test Ubuntu x64 Checked jitx86hwintrinsicnoavx2
@dotnet-bot test Ubuntu x64 Checked jitx86hwintrinsicnosimd
@dotnet-bot test Ubuntu x64 Checked jitnox86hwintrinsic

[tannergooding]

@dotnet-bot test Ubuntu x64 Checked gcstress0xc
@dotnet-bot test Ubuntu x64 Checked gcstress0xc_minopts_heapverify1

@dotnet-bot test Windows_NT x64 Checked gcstress0xc
@dotnet-bot test Windows_NT x64 Checked gcstress0xc_minopts_heapverify1

[tannergooding]

CC. @AndyAyersMS, @CarolEidt, @fiigii

[tannergooding]

New entries are:

case INS_andn:
case INS_blsi:
case INS_blsmsk:
case INS_blsr:
case INS_movmskpd:
case INS_movmskps:
case INS_pdep:
case INS_pext:
case INS_pextrw_sse41:

[tannergooding]

I wasn't actually getting GCStress failures for the RWR_RRD_ARD (as well as the corresponding SRD, MRD, and RRD) entries... However, we are definitely executing SIMD instructions that write integer registers and that use those formats....

Anyone know if there is something I'm missing here?

[AndyAyersMS]

You may just be getting (un)lucky, as the written registers won't always contain GC refs.

[tannergooding]

As a general comment, when reviewing I saw at least a couple IF_* entries that didn't make much sense (such as IF_RRW_RRW_CNS)... We should probably audit the instructions and the formats they get mapped to in order so we can validate they are accurate.

[tannergooding]

@CarolEidt, @AndyAyersMS do either of you have any concerns with merging this?

• The Win x64 HeapVerify/GCStress job timed out, everything passes locally.
• The OSX10.12 failure is in Avx_ro, but is unrelated to this change (still investigating locally).
• The Ubuntu GCStress jobs have been running for 17 hours now (and are still going, they don't appear to be stalled)

[CarolEidt]

LGTM

[CarolEidt]

Added a note to #14523 about this.

[AndyAyersMS]

LGTM too.

I think you can use jit-diffs to check for GC reporting diffs (though it might require manual file diffing).

Might be interesting to see if anything turns up from this outside of methods that use these HW intrinsics.

[tannergooding]

Might be interesting to see if anything turns up from this outside of methods that use these HW intrinsics.

Good idea, will check this before merging.

[tannergooding]

corelib reported 0 diffs. Test diffs are still running.

[tannergooding]

Only Bmi1 reported diffs, and only for the gcinfo portion.

[AndyAyersMS]

Thanks for checking. That explains why you didn't see other stress failures ...

[tannergooding]

That explains why you didn't see other stress failures .

Right. They must be getting updated somewhere else, and I missed it somewhere. (I know RRW_RRW_RRD was handle explicitly after the emitOutputRR call, for example).