[llvm] [SPIR-V] Rework usage of virtual registers' types and classes (PR #101732)

[Vyacheslav Levytskyy via llvm-commits]

================
@@ -308,93 +308,104 @@ static void widenScalarLLTNextPow2(Register Reg, MachineRegisterInfo &MRI) {
     MRI.setType(Reg, LLT::scalar(NewSz));
 }
 
+inline bool getIsFloat(SPIRVType *SpvType, const SPIRVGlobalRegistry &GR) {
+  bool IsFloat = SpvType->getOpcode() == SPIRV::OpTypeFloat;
+  return IsFloat ? true
+                 : SpvType->getOpcode() == SPIRV::OpTypeVector &&
+                       GR.getSPIRVTypeForVReg(SpvType->getOperand(1).getReg())
+                               ->getOpcode() == SPIRV::OpTypeFloat;
+}
+
+static const TargetRegisterClass *getRegClass(SPIRVType *SpvType,
+                                              const SPIRVGlobalRegistry &GR) {
+  unsigned Opcode = SpvType->getOpcode();
+  switch (Opcode) {
+  case SPIRV::OpTypeFloat:
+    return &SPIRV::fIDRegClass;
+  case SPIRV::OpTypePointer:
+    return GR.getPointerSize() == 64 ? &SPIRV::pID64RegClass
+                                     : &SPIRV::pID32RegClass;
+  case SPIRV::OpTypeVector: {
+    SPIRVType *ElemType =
+        GR.getSPIRVTypeForVReg(SpvType->getOperand(1).getReg());
+    unsigned ElemOpcode = ElemType ? ElemType->getOpcode() : 0;
+    if (ElemOpcode == SPIRV::OpTypeFloat)
+      return &SPIRV::vfIDRegClass;
+    if (ElemOpcode == SPIRV::OpTypePointer)
+      return GR.getPointerSize() == 64 ? &SPIRV::vpID64RegClass
----------------
VyacheslavLevytskyy wrote:

A hard coded `LLT LLTy = LLT::scalar(32);` doesn't always look very well for sure, and this PR is exactly a step towards a better direction. So, a short answer would be just yes, because virtual registers logic is too coupled between passes to simply keep all registers spirv's scalar 32 or to start describing spirv types by low-level types. A better answer, thought, is that this PR is only a beginning of getting virtual registers more consistent.

Passes before instruction selection need to operate with valid virtual registers types and classes, whereas the instruction selection pass starts to use SPIRVInstrInfo.td where virtual registers (valid from the perspective of Machine Verifier) start to fail in pattern matching and don't match very well to SPIRV spec.

What I'm going to do to gradually get things more consistent is to try simplifying SPIRVInstrInfo.td in the next PR and hopefully get rid of 32 vs. 64 bit register classes. The instruction selection pass is a border between LLVM notion of valid vreg and SPIRV concept of <id>, and it looks right to address SPIRVInstrInfo.td first and then get back to previous passes implementation to try simplify their logic as well.

https://github.com/llvm/llvm-project/pull/101732