search for: mov32rr

...EXCEPT RAX die (last use). > > Again, what's > > the deal with RAX? EAX is redefined just a few instructions later, > > which > > should kill RAX. The [34,50:0)[50,54:1) interval for RAX is just > > weird. Why > > isn't it [34,54)? > > 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> > MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> > > Def of sub-register use and define its super-register(s). I can't quite parse that. > So RAX's live range isn't broken here. How is...

...>>> Again, what's >>> the deal with RAX? EAX is redefined just a few instructions later, >>> which >>> should kill RAX. The [34,50:0)[50,54:1) interval for RAX is just >>> weird. Why >>> isn't it [34,54)? >> >> 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> >> MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> >> >> Def of sub-register use and define its super-register(s). > > I can't quite parse that. Definition of a sub-register implicitly...

...f> > > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > > > So their live ranges start at 28+2. > > Yep, this makes sense to me. But AL is a subregister of RAX too, > so shouldn't it have a live interval that starts there as well? > > 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> > > MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> > > > > Def of sub-register use and define its super-register(s). > > I can't quite parse that. > > 48 %EAX = MOV32rr %reg1...

...gt; %mreg(110)<d> %mreg(97)<d> %mreg(98)<d> %mreg(99)<d> %mreg(100)<d> %mreg(101)<d> %mreg(102)<d> %mreg(17)<d> 36 ADJCALLSTACKUP 0, 0, %ESP<imp-def>, %ESP<imp-use> ADJCALLSTACKUP 0 0 %mreg(25)<d> %mreg(25) 40 %reg1026<dead> = MOV32rr %EAX<kill> MOV32rr %reg1026<d> %mreg(17) 44 %reg1027 = MOV32r0 MOV32r0 %reg1027<d> 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> 52 RET %EAX<imp-use,kill>, %RAX<imp-us...

...y failing the following assertion: llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. when attempting to allocate this machine function: entry: 4 %reg1024<def,dead> = MOV32rr %EDI<kill> 12 %reg1025<def,dead> = MOV64rr %RSI<kill> 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> 28 %reg1026<def> = MOV8ri 4 36 %reg1027<def> = FsFLD0SD 44 %reg1028<def> = LEA64r %reg0, 1,...

...rs. This happens because, on entry to the pass, we have %RAX<def> = SUBREG_TO_REG 0, %R9D, 4 %XMM0<def> = MOV64toPQIrr %RAX<kill> The pass converts (around about line 132 in ExpandPostRAPseudos.cpp) the SUBREG_TO_REG pseudo op to %EAX<def> = MOV32rr %R9D Because of "-mcpu-atom", post RA scheduling is enabled, so is post RA liveness tracking. Because the destination has been changed to EAX from RAX in transforming the SUBREG_TO_REG pseudo op into a MOV32rr, liveness checking fails in MachineVerifier.cpp. Would anyone be able to com...

...slot 42 all of the A registers EXCEPT RAX die (last use). > Again, what's > the deal with RAX? EAX is redefined just a few instructions later, > which > should kill RAX. The [34,50:0)[50,54:1) interval for RAX is just > weird. Why > isn't it [34,54)? 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> Def of sub-register use and define its super-register(s). So RAX's live range isn't broken here. > > Finally, according to the above live interval...

...: VirtRegMap.cpp:1733: > void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, > llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. > > > when attempting to allocate this machine function: > > entry: > 4 %reg1024<def,dead> = MOV32rr %EDI<kill> > 12 %reg1025<def,dead> = MOV64rr %RSI<kill> > 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, > %ESP<imp-use> > 28 %reg1026<def> = MOV8ri 4 > 36 %reg1027<def> = FsFLD0SD > 44 %reg10...

...XCEPT RAX die (last use). >> Again, what's >> the deal with RAX? EAX is redefined just a few instructions >> later, which >> should kill RAX. The [34,50:0)[50,54:1) interval for RAX is just >> weird. Why >> isn't it [34,54)? > > 48 %EAX = MOV32rr %reg1027<kill>, %RAX<imp-use,kill>, %RAX<imp-def> > MOV32rr %mreg(17)<d> %reg1027 %mreg(74) %mreg(74)<d> > > Def of sub-register use and define its super-register(s). So RAX's > live range isn't broken here. > >> >> Finally, accord...

...by using a subregister for the address (which is zero-extended, effectively ignoring the metadata bits). As a side note, GCC does emit the second snippet as expected. Looking at the TableGen files I found two problems: 1. The AND of the address with 0xffffffff is replaced with SUBREG_TO_REG(MOV32rr (EXTRACT_SUBREG ...)) in lib/Target/X86/X86InstrCompiler.td (line 1326). That MOV32rr emits an explicit mov instruction later. I think I need to replace this with (i32 (EXTRACT_SUBREG ...)) to get rid of the mov, but that produces a 32-bit value, which leads me to the next, more general problem...

...i=0; i <= lastAddrIndx; ++i) (*MIB).addOperand(*argOpers[i]); MIB.addReg(t2); - + assert(bInstr->hasOneMemOperand() && "Unexpected number of memoperand"); + (*MIB).addMemOperand(*F, *bInstr->memoperands_begin()); + MIB = BuildMI(newMBB, TII->get(X86::MOV32rr), destOper.getReg()); MIB.addReg(X86::EAX); @@ -6107,6 +6109,8 @@ for (int i=0; i <= lastAddrIndx; ++i) (*MIB).addOperand(*argOpers[i]); MIB.addReg(t3); + assert(mInstr->hasOneMemOperand() && "Unexpected number of memoperand"); + (*MIB).addMemOperand(*...

...ess (which is zero-extended, effectively > ignoring the metadata bits). As a side note, GCC does emit the second > snippet as expected. > > > Looking at the TableGen files I found two problems: > > 1. The AND of the address with 0xffffffff is replaced with > SUBREG_TO_REG(MOV32rr (EXTRACT_SUBREG ...)) in > lib/Target/X86/X86InstrCompiler.td (line 1326). That MOV32rr emits an > explicit mov instruction later. I think I need to replace this with > (i32 (EXTRACT_SUBREG ...)) to get rid of the mov, but that produces a > 32-bit value, which leads me to the next,...

...k like for these basic blocks. falseBlock (0xa60cb18, LLVM BB @0xa5ce378, ID#81): Predecessors according to CFG: 0xa60ca80 %EAX = MOV32ri 617 %EBX = MOV32rm %EBP, 1, %NOREG, -12 %EDI = MOV32rm %EBP, 1, %NOREG, -8 %ESI = MOV32rm %EBP, 1, %NOREG, -4 %ESP = MOV32rr %EBP %EBP = POP32r RET codeRepl (0xa5f4148, LLVM BB @0xa5ce310, ID#82): Predecessors according to CFG: 0xa60ca80 %EDI = INC32r %EDI %EAX = MOV32rm %EBP, 1, %NOREG, -268 MOV32mr %EAX, 1, %NOREG, 0, %EDI CALLpcrel32 <ga:test3_trueBlock_trueBlock...

...s, as far as I can tell, it's not really possible to mix the two using tablegen? In the hardware, every instruction can either take an A register or a B register, in tablegen (as far as I can understand) this is not possible. I ended up creating instructions like MOV32ri (register immediate) MOV32rr (register register) MOV64rr, MOV64ri etc. I've done this for essentially every instruction. This kind of works, but there are issues. It results in unneeded copies between A registers and B registers. If a value is in an A register and the other is in a B, LLVM will do a copy between register...

...rm <fi#2>, 1, %reg0, 4, %reg0 ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> %reg1030<def> = LEA64r %RIP, 1, %reg0, <ga:@.str> %reg1031<def> = MOV8r0 %EFLAGS<imp-def,dead> %RDI<def> = MOV64rr %reg1030 %ESI<def> = MOV32rr %reg1028 %EDX<def> = MOV32rr %reg1029 %AL<def> = MOV8rr %reg1031 CALL64pcrel32 <ga:@printf>, %RDI, %ESI, %EDX, %AL, %RAX<imp-def>, %RDX<imp-def>, %RSI<imp-def>, %RDI<imp-def>, %RSP<imp-use>, ... When finding a register for %reg1028, RAFast sees th...

...ADJCALLSTACKDOWN 8 %reg1028 = ADD32rr %reg1026, %reg1027 %reg1029 = IMUL32rr %reg1028, %reg1027 MOV32mr %ESP, 1, %NOREG, 4, %reg1029 MOV32mi %ESP, 1, %NOREG, 0, <ga:.str_1> CALLpcrel32 <ga:printf> ADJCALLSTACKUP 8, 0 %reg1030 = MOV32rr %EAX %reg1031 = IMPLICIT_DEF_GR32 %EAX = MOV32rr %reg1031 RET My allocator produces this mapping: FNSTCW16m := MOV8mi := FLDCW16m := MOV32rm EAX := MOV32rm EAX := EAX MOVSX32rm8 ECX := EAX MOVSX32rm...

...d46970): | FNSTCW16m <fi#0>, 1, %NOREG, 0 int main() { | MOV8mi <fi#0>, 1, %NOREG, 1, 2 return 0; | FLDCW16m <fi#0>, 1, %NOREG, 0 } | %reg1024 = MOV32r0 | %EAX = MOV32rr %reg1024 | RET llc((anonymous namespace)::PrintStackTrace()+0x18)[0x88cfa30] llc((anonymous namespace)::SignalHandler(int)+0x107)[0x88cfcc1] /lib/tls/libc.so.6[0x239f48] llc(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x28)[0x8400638] llc(llvm::Functi...

...| FNSTCW16m <fi#0>, 1, %NOREG, 0 > int main() { | MOV8mi <fi#0>, 1, %NOREG, 1, 2 > return 0; | FLDCW16m <fi#0>, 1, %NOREG, 0 > } | %reg1024 = MOV32r0 > | %EAX = MOV32rr %reg1024 > | RET > > llc((anonymous namespace)::PrintStackTrace()+0x18)[0x88cfa30] > llc((anonymous namespace)::SignalHandler(int)+0x107)[0x88cfcc1] > /lib/tls/libc.so.6[0x239f48] > llc(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x28)...

...t; = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * MOV32mr %reg0, 1, %reg0, <ga:@one+4>, %reg0, %EAX<kill>* * %EAX<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * ADJCALLSTACKDOWN32 8, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use>* * %ECX<def> = MOV32rr %ESP* * MOV32mr %ECX, 1, %reg0, 4, %reg0, %EAX<kill>; mem:ST4[Stack+4]* * MOV32mi %ECX<kill>, 1, %reg0, 0, %reg0, <ga:@.str>; mem:ST4[Stack]* * CALLpcrel32 <ga:@printf>, %EAX<imp-def>, %ECX<imp-def,dead>, %ESP<imp-use>, ...* * ADJCALLSTACKUP32 8, 0, %ESP&lt...

...FNSTCW16m <fi#0>, 1, %NOREG, 0 > > int main() { | MOV8mi <fi#0>, 1, %NOREG, 1, 2 > > return 0; | FLDCW16m <fi#0>, 1, %NOREG, 0 > > } | %reg1024 = MOV32r0 > > | %EAX = MOV32rr %reg1024 > > | RET > > > > llc((anonymous namespace)::PrintStackTrace()+0x18)[0x88cfa30] > > llc((anonymous namespace)::SignalHandler(int)+0x107)[0x88cfcc1] > > /lib/tls/libc.so.6[0x239f48] > > llc(llvm::MachineFunctionPass::runOnFunct...