[llvm] Try To Guess SGMasks for Inline Asm Instructions (PR #155491)

Patrick Simmons via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 21 14:47:45 PST 2026


================
@@ -2391,6 +2393,62 @@ bool SchedGroup::canAddMI(const MachineInstr &MI) const {
   if (MI.isMetaInstruction())
     Result = false;
 
+  else if (MI.isInlineAsm()) {
+    const SIRegisterInfo &TRI = TII->getRegisterInfo();
+    auto &MRI = MI.getParent()->getParent()->getRegInfo();
+    bool SGPR_used = false, SGPR_big_def = false, VGPR_used = false,
+         VMFMA_used = false, VReg32_used = false, MayLoad = MI.mayLoad(),
+         MayStore = MI.mayStore();
+    for (const MachineOperand &Operand : MI.operands())
+      if (Operand.isReg()) {
+        const TargetRegisterClass &RegClass =
+            *TRI.getRegClassForOperandReg(MRI, Operand);
+        if (TRI.hasVGPRs(&RegClass)) {
+          VGPR_used = true;
+          if (Operand.isUse() && TRI.getRegSizeInBits(RegClass) == 32)
+            VReg32_used = true;
+        }
+        // > 128 bit registers are usually only used by MFMA instructions, so
+        // we're using that as a heuristic to guess the schedule group mask of
+        // the inline asm.
+        if (TRI.hasAGPRs(&RegClass) || TRI.getRegSizeInBits(RegClass) > 128)
+          VMFMA_used = true;
+        if (TRI.hasSGPRs(&RegClass))
+          SGPR_used = true;
+        if (TRI.getRegSizeInBits(RegClass) > 64 && Operand.isDef())
+          SGPR_big_def = true;
+      }
+
+    typedef std::underlying_type_t<SchedGroupMask> SGMask_t;
----------------
linuxrocks123 wrote:

@arsenm I feel like this is the right way to be robust against the enum growing.  That would silently change the underlying type to a long and cause problems with hard-coding `int` which is the currently correct underlying type.  I could hard-code `uint64_t` instead of `int`, of course, but it feels better to just guarantee we'll always use the right type here.  I mean, after all, we could eventually use a 128-bit enum, right?

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


More information about the llvm-commits mailing list