X86AsmPrinter doesn't know how to handle the X86II::MO_GOT_ABSOLUTE_ADDRESS flag
authorJakob Stoklund Olesen <stoklund@2pi.dk>
Sat, 30 Apr 2011 23:00:05 +0000 (23:00 +0000)
committerJakob Stoklund Olesen <stoklund@2pi.dk>
Sat, 30 Apr 2011 23:00:05 +0000 (23:00 +0000)
after folding ADD32ri to ADD32mi, so don't do that.

This only happens when the greedy register allocator gets itself in trouble and
spills %vreg9 here:

16L             %vreg9<def> = MOVPC32r 0, %ESP<imp-use>; GR32:%vreg9
48L             %vreg9<def> = ADD32ri %vreg9, <es:_GLOBAL_OFFSET_TABLE_>[TF=1], %EFLAGS<imp-def,dead>; GR32:%vreg9

That should never happen, the live range should be split instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130625 91177308-0d34-0410-b5e6-96231b3b80d8

lib/Target/X86/X86InstrInfo.cpp

index c48ea154adcb73f4aa3727d60afb2331c1d9d136..83f0260d63b4fdbe60338b4a74456b118b258e25 100644 (file)
@@ -2240,6 +2240,12 @@ X86InstrInfo::foldMemoryOperandImpl(MachineFunction &MF,
   bool isTwoAddr = NumOps > 1 &&
     MI->getDesc().getOperandConstraint(1, TOI::TIED_TO) != -1;
 
+  // FIXME: AsmPrinter doesn't know how to handle
+  // X86II::MO_GOT_ABSOLUTE_ADDRESS after folding.
+  if (MI->getOpcode() == X86::ADD32ri &&
+      MI->getOperand(2).getTargetFlags() == X86II::MO_GOT_ABSOLUTE_ADDRESS)
+    return NULL;
+
   MachineInstr *NewMI = NULL;
   // Folding a memory location into the two-address part of a two-address
   // instruction is different than folding it other places.  It requires
@@ -2534,6 +2540,12 @@ bool X86InstrInfo::canFoldMemoryOperand(const MachineInstr *MI,
     case X86::TEST32rr:
     case X86::TEST64rr:
       return true;
+    case X86::ADD32ri:
+      // FIXME: AsmPrinter doesn't know how to handle
+      // X86II::MO_GOT_ABSOLUTE_ADDRESS after folding.
+      if (MI->getOperand(2).getTargetFlags() == X86II::MO_GOT_ABSOLUTE_ADDRESS)
+        return false;
+      break;
     }
   }