search for: fsmovlpdrm

...problem. I'm merging our graph coloring allocator with the code from trunk as of late last week. I have a code where a LiveInterval is spilled and some uses can be rematerialized. %reg1235 is spilled and at least one use is rematted. The remat def instruction is: %reg1235<def> = FsMOVLPDrm %reg1097, 1, %reg1364, 88, Mem:LD(8,8) [tmp17731774 + 0] So this gets entered into ReMatDefs. %reg1461 is created for one of the spill intervals of %reg1235. It is marked as rematerializable with defining instruction: %reg1235<def> = FsMOVLPDrm %reg1097, 1, %reg1364, 8, Mem:LD(8,8) [tmp...

...lot 4. The first spilled register is assigned stack slot 6 so LowSpillSlot == 6. Then, when we try to erase from SpillSlotToUsesMap, we index with a negative number. The instruction being removed is generated by instruction selection, so it is part of the original program: %reg1309<def> = FsMOVLPDrm <fi#4>, 1, %reg0, 0, Mem:LD(8,8) [ZETA + 0] Since we're hooking up llvm to custom code, I want to check assumptions. Is there anything in llvm-gcc or the other llvm tools that could generate a stack slot reference like this before register allocation? Basically, I'm trying to see i...

...r is > assigned stack slot 6 so LowSpillSlot == 6. Then, when we try to > erase from SpillSlotToUsesMap, we index with a negative number. > > The instruction being removed is generated by instruction selection, > so it is part of the original program: > > %reg1309<def> = FsMOVLPDrm <fi#4>, 1, %reg0, 0, Mem:LD(8,8) [ZETA + 0] > > Since we're hooking up llvm to custom code, I want to check > assumptions. > Is there anything in llvm-gcc or the other llvm tools that could > generate a > stack slot reference like this before register allocation?...