Cleanup some xarch emit logic

[tannergooding]

I was working on a emitValidateIns method (debug-only, run as part of emitDispIns) which verifies that the various instrDesc we encounter are "correct". As part of this, I found a few places where things are currently incorrect and should be updated. -- The emitValidateIns will go up eventually, but as its own PR given size/complexity and because there are still more validation that needs to be done.

In particular:

• Several instructions were not going down the VEX path and were giving potentially incorrect disassembly
• Several instructions were not passing down a valid emitAttr (they passed down a scalar size to a vector instruction)
• Several instructions were using an incorrect insFormat

Most of these were straightfoward fixes. However, we also had but were not using some "scheduling" information that was defined as part of the emitfmt data. I added functions to be able to query that information and utilize it in a few places rather than checking giant switch tables. -- There are more places this could be used as well, such as in the GC liveness update checks and to remove code duplication in places like emitDispIns. However, those can be done in their own PRs.

[ghost]

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

Issue Details

---

I was working on a emitValidateIns method (debug-only, run as part of emitDispIns) which verifies that the various instrDesc we encounter are "correct". As part of this, I found a few places where things are currently incorrect and should be updated. -- The emitValidateIns will go up eventually, but as its own PR given size/complexity and because there are still more validation that needs to be done.

In particular:

• Several instructions were not going down the VEX path and were giving potentially incorrect disassembly
• Several instructions were not passing down a valid emitAttr (they passed down a scalar size to a vector instruction)
• Several instructions were using an incorrect insFormat

Most of these were straightfoward fixes. However, we also had but were not using some "scheduling" information that was defined as part of the emitfmt data. I added functions to be able to query that information and utilize it in a few places rather than checking giant switch tables. -- There are more places this could be used as well, such as in the GC liveness update checks and to remove code duplication in places like emitDispIns. However, those can be done in their own PRs.

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

[tannergooding]

The EVEX versions of these instructions produce a K register, not a XMM/YMM/ZMM register.

Since they need entirely different handling (and cannot be freely converted between the two forms), they need to be their own instructions.

[tannergooding]

b/w instructions are typically FULL_MEM while d/q are typically FULL (with a few exceptions)

In this case, they should've been FULL

[tannergooding]

The various test instructions don't mutate either input; the operate in a temp and set flags.

[tannergooding]

FMA instructions are all RMW

[tannergooding]

EVEX only instructions don't need to specify REX_W1_EVEX since they don't have a different encoding for non-EVEX.

They can just specify REX_W1 directly and go down the faster path

[tannergooding]

CRC32 is an RMW instruction

[tannergooding]

CC. @dotnet/jit-contrib

Diffs

We see good TP wins of up to -0.20% in minopts and up to -0.03% in fullopts.

We also see some smaller assembly both from consistent use of the VEX aware path and from using the correct insFormat for various instructions as it allows various instruction peepholes to light-up better.

[tannergooding]

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

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[tannergooding]

Fuzzlyn failure is pre-existing and repros on .NET 8 Preview 3: #85602

[EgorBo]

The changes make sense to me assuming CI is green

[tannergooding]

Merged in dotnet/main to resolve the conflicts caused by #85594

[tannergooding]

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

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[tannergooding]

JitStress failures are #85608

[sebastienros]

Do you think this PR could explain this improvement?

[tannergooding]

It's possible, but hard to say for certain without seeing the codegen.

This fixed up a number of code paths dealing with vectors to be VEX aware and emit more optimal codegen.