AMDGPU: Define mode register

[arsenm]

Summary

This should eventually model FP mode constraints as well as the other
special fields it tracks.

[rampitec]

I would define individual fields as separate registers. That way we will be able to reschedule instructions across some mode changes if these instructions are not affected by a particular change.

[arsenm]

In D72175#1803537, @rampitec wrote:

I would define individual fields as separate registers. That way we will be able to reschedule instructions across some mode changes if these instructions are not affected by a particular change.

I think that's way overcomplicated, especially for the frequency of mode writes. There's a cost to adding each register and register operand

[rampitec]

In D72175#1803554, @arsenm wrote:

In D72175#1803537, @rampitec wrote:

I would define individual fields as separate registers. That way we will be able to reschedule instructions across some mode changes if these instructions are not affected by a particular change.

I think that's way overcomplicated, especially for the frequency of mode writes. There's a cost to adding each register and register operand

We used to have this optimization with HSAIL and it deemed to be quite profitable.

[arsenm]

In D72175#1803565, @rampitec wrote:

In D72175#1803554, @arsenm wrote:

In D72175#1803537, @rampitec wrote:

I would define individual fields as separate registers. That way we will be able to reschedule instructions across some mode changes if these instructions are not affected by a particular change.

I think that's way overcomplicated, especially for the frequency of mode writes. There's a cost to adding each register and register operand

We used to have this optimization with HSAIL and it deemed to be quite profitable.

Unlike HSAIL, in LLVM the FP mode is going to be a middle end, IR problem. The backend won't be responsible for inserting or maintaining mode switches. All of that should be done in the IR on the constrained FP intrinsics. Separately tracking the bits on the machine level is going to increase the cost and complexity too much (just the one I think is too much, but manageable)

[arsenm]

Rebase and fix asserts when actually used

[rampitec]

In D72175#2050379, @arsenm wrote:

Unlike HSAIL, in LLVM the FP mode is going to be a middle end, IR problem. The backend won't be responsible for inserting or maintaining mode switches. All of that should be done in the IR on the constrained FP intrinsics. Separately tracking the bits on the machine level is going to increase the cost and complexity too much (just the one I think is too much, but manageable)

Well, actually it was in the SC, so backend. The point to split it is to be able to reschedule without false dependencies and to minimize required switches. At the very least we need to minimize switches.

[arsenm]

In D72175#2051296, @rampitec wrote:

In D72175#2050379, @arsenm wrote:

Unlike HSAIL, in LLVM the FP mode is going to be a middle end, IR problem. The backend won't be responsible for inserting or maintaining mode switches. All of that should be done in the IR on the constrained FP intrinsics. Separately tracking the bits on the machine level is going to increase the cost and complexity too much (just the one I think is too much, but manageable)

Well, actually it was in the SC, so backend. The point to split it is to be able to reschedule without false dependencies and to minimize required switches. At the very least we need to minimize switches.

Minimizing the switches is an IR problem. The backends isn’t going to be responsible for scheduling instructions around mode switches, and we just need to express the possible dependency. You can handle those issues in an IR pass that understands setreg intrinsic calls and constrained intrinsics. The other issue with breaking this down is the documentation for which instructions read which sub fields is quite poor and varies per subtarget (at least for the denormal mode). We would also have to understand the mode switch perfectly, which won’t always be the case if a variable setting is used with s_setreg. In the immediate case we would have to define a lot of variants of setreg setting different mode bit sets

[rampitec]

OK, let's try to handle it in IR.

[arsenm]

2e82667f60237c32d8a10eb04825ff434a3e474c

llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp

for (const MachineInstr &MI : MBB) {
         case AMDGPU::EXEC_HI:
         case AMDGPU::SCC:
         case AMDGPU::M0:
         case AMDGPU::SRC_SHARED_BASE:
         case AMDGPU::SRC_SHARED_LIMIT:
         case AMDGPU::SRC_PRIVATE_BASE:
         case AMDGPU::SRC_PRIVATE_LIMIT:
         case AMDGPU::SGPR_NULL:
+        case AMDGPU::MODE:
           continue;
 
         case AMDGPU::SRC_POPS_EXITING_WAVE_ID:
           llvm_unreachable("src_pops_exiting_wave_id should not be used");
 
         case AMDGPU::NoRegister:
           assert(MI.isDebugInstr());
           continue;

llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp

MCRegister SIRegisterInfo::reservedPrivateSegmentBufferReg(
   const MachineFunction &MF) const {
   unsigned BaseIdx = alignDown(ST.getMaxNumSGPRs(MF), 4) - 4;
   MCRegister BaseReg(AMDGPU::SGPR_32RegClass.getRegister(BaseIdx));
   return getMatchingSuperReg(BaseReg, AMDGPU::sub0, &AMDGPU::SGPR_128RegClass);
 }
 
 BitVector SIRegisterInfo::getReservedRegs(const MachineFunction &MF) const {
   BitVector Reserved(getNumRegs());
+  Reserved.set(AMDGPU::MODE);
 
   // EXEC_LO and EXEC_HI could be allocated and used as regular register, but
   // this seems likely to result in bugs, so I'm marking them as reserved.
   reserveRegisterTuples(Reserved, AMDGPU::EXEC);
   reserveRegisterTuples(Reserved, AMDGPU::FLAT_SCR);
 
   // M0 has to be reserved so that llvm accepts it as a live-in into a block.
   reserveRegisterTuples(Reserved, AMDGPU::M0);

 SIRegisterInfo::getRegClassForReg(const MachineRegisterInfo &MRI,
                                   Register Reg) const {
   return Reg.isVirtual() ? MRI.getRegClass(Reg) : getPhysRegClass(Reg);
 }
 
 bool SIRegisterInfo::isVGPR(const MachineRegisterInfo &MRI,
                             Register Reg) const {
   const TargetRegisterClass *RC = getRegClassForReg(MRI, Reg);
-  assert(RC && "Register class for the reg not found");
-  return hasVGPRs(RC);
+  // Registers without classes are unaddressable, SGPR-like registers.
+  return RC && hasVGPRs(RC);
 }
 
 bool SIRegisterInfo::isAGPR(const MachineRegisterInfo &MRI,
                             Register Reg) const {
   const TargetRegisterClass *RC = getRegClassForReg(MRI, Reg);
-  assert(RC && "Register class for the reg not found");
-  return hasAGPRs(RC);
+
+  // Registers without classes are unaddressable, SGPR-like registers.
+  return RC && hasAGPRs(RC);
 }
 
 bool SIRegisterInfo::shouldCoalesce(MachineInstr *MI,
                                     const TargetRegisterClass *SrcRC,
                                     unsigned SubReg,
                                     const TargetRegisterClass *DstRC,
                                     unsigned DstSubReg,
                                     const TargetRegisterClass *NewRC,

llvm/lib/Target/AMDGPU/SIRegisterInfo.td

 defm SGPR_NULL : SIRegLoHi16 <"null", 125>;
 
 defm SRC_SHARED_BASE : SIRegLoHi16<"src_shared_base", 235>;
 defm SRC_SHARED_LIMIT : SIRegLoHi16<"src_shared_limit", 236>;
 defm SRC_PRIVATE_BASE : SIRegLoHi16<"src_private_base", 237>;
 defm SRC_PRIVATE_LIMIT : SIRegLoHi16<"src_private_limit", 238>;
 defm SRC_POPS_EXITING_WAVE_ID : SIRegLoHi16<"src_pops_exiting_wave_id", 239>;
 
+// Not addressable
+def MODE : SIReg <"mode", 0>;
+
 def LDS_DIRECT : SIReg <"src_lds_direct", 254> {
   // There is no physical register corresponding to this. This is an
   // encoding value in a source field, which will ultimately trigger a
   // read from m0.
   let isArtificial = 1;
 }
 
 defm XNACK_MASK_LO : SIRegLoHi16<"xnack_mask_lo", 104>;