SIFixSGPRCopies handled STRICT_WWM (and similar WWM/WQM pseudos) like a
COPY. In particular, if the source was a VGPR and the result was an
SGPR, lowerVGPR2SGPRCopies would replace it with a readfirstlane,
erasing the original pseudo and hence sabotaging the WWM region marking
which is supposed to be performed by SIWholeQuadMode.

Fix this by handling it more like INSERT_SUBREG, PHI and REG_SEQUENCE:
if the source is a VGPR then move the result to a VGPR, and keep the
pseudo.

i16 can be selected into sgpr32 or vgpr16 in isel lowering in true16
mode. And thus, it creates cases that we copy from vgpr16 to sgpr32 in
ext selection and this seems inevitable without sgpr16 support.

legalize the src/dst reg when we decide to lower this special copy to a
readfirstlane in fix-sgpr-copy pass and add a lit test

LIT tests which were incorrectly merged are corrected.

This reverts commit 0563569978fee1e780a560494c89869074933f58.

Breaks tests, see comments on https://github.com/llvm/llvm-project/pull/134153

PHI operands and results must belong to the same register class.
If a PHI node produces an SGPR, but one of its operands is a VGPR, we
insert a VGPR-to-SGPR copy in the operand’s source block. The PHI
operand is then updated to use the destination register of the inserted
copy.

These inserted copies are processed immediately when they are created.
Therefore, we should avoid reprocessing them when handling their parent
block later.

---------

Co-authored-by: Matt Arsenault <arsenm2@gmail.com>

Insert the start instruction directly into the map before the uses. This
prevents improperly re-visting sgpr->vgpr phi inputs multiple times
which
would trigger a use after free.

I don't particularly trust the iteration scheme here. This is also
unnecessarily revisting transitive users of a phi or reg_sequence for
every
input operand, but I will address that separately.

Fixes #130646. I also believe it fixes #130119, although that test fails
less consistently for me.

M0 can only be written to by the SALU, so `v_readfirstlane_b32 m0` is
effectively useless. Represent this by restricting the dest RC of that
instruction to `SReg_32_XM0` which excludes M0.

There is a lot of test changes due to the register class changing, but
most changes are trivial. In some cases, an extra register and
`s_mov_b32` is needed.

Fixes SWDEV-513269