search for: add64ri32

>> // Increment loop variable and jmp >> BuildMI(*MBB_erase, MBB_erase->end(), db, >> TII->get(X86::ADD64ri32),reg).addReg(reg).addImm(8); > > It looks like this instruction is defining virtual register "reg" the second time. Thx for your answer... Why would it define it again? I just want to use this register and add something to it... Cheers

...7<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr %reg1230<kill> 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 328 %reg1135 = MOVSX64rr32 %reg1025 332 %reg1136 = MOV64rr %reg1135<kill> 336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead> 340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def> 344 JNS mbb<file solve.f, line 23, in loop at depth 1, bb16,0x83a2c70>, %EFLAGS<imp-use,kill> Here we have the curious case of %reg1055 being defined and then immediately kill...

...MBB(MBB).addReg(reg).addMBB(MBB_erase); // Erase content of stack BuildMI(*MBB_erase, MBB_erase->end(), db, TII->get(X86::MOV32mi)) .addReg(reg).addImm(1).addReg(0).addImm(0).addReg(0) .addImm(0); // Increment loop variable and jmp BuildMI(*MBB_erase, MBB_erase->end(), db, TII->get(X86::ADD64ri32), reg).addReg(reg).addImm(8); BuildMI(*MBB_erase, MBB_erase->end(), db, TII->get(X86::JMP_4)).addMBB(MBB_cond); // Erase intrinsic MI->eraseFromParent(); MBB->getParent()->dump(); return MBB_cond; } Here is the dump of the original function before my custom inserter (it's basica...

...OV64rr %reg1228<kill> > 316 %reg1053 = MOV64rr %reg1229<kill> > 320 %reg1054 = MOV64rr %reg1230<kill> > 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 > 328 %reg1135 = MOVSX64rr32 %reg1025 > 332 %reg1136 = MOV64rr %reg1135<kill> > 336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead> > 340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def> > 344 JNS mbb<file solve.f, line 23, in loop at depth 1, > bb16,0x83a2c70>, > %EFLAGS<imp-use,kill> David, could you post the live ins/outs for the block? My th...

..., MBB_cond->end(), db, TII->get(X86::JE_4)).addMBB(MBB_end); // mov dword[reg], 0x0 BuildMI(*MBB_erase, MBB_erase->end(), db, TII->get(X86::MOV32mi)).addReg(regB).addImm(1).addReg(0).addImm(0).addReg(0).addImm(0); BuildMI(*MBB_erase, MBB_erase->end(), db, TII->get(X86::ADD64ri32), regC).addReg(regB).addImm(8); BuildMI(*MBB_cond, MBB_erase->end(), db, TII->get(X86::JMP_4)).addMBB(MBB_cond); // Erase intrinsic MI->eraseFromParent(); MBB->getParent()->dump(); return MBB_erase; } I run it on this sample code: #include <stdio.h> int...

...%EFLAGS<imp-def>; GR64:%vreg8 JE_4 <BB#3>, %EFLAGS<imp-use> Successors according to CFG: BB#2 BB#3 BB#2: derived from LLVM BB %entry Predecessors according to CFG: BB#1 MOV32mi %vreg8, 1, %noreg, 0, %noreg, 0; GR64:%vreg8 %vreg9<def,tied1> = ADD64ri32 %vreg8<tied0>, 8, %EFLAGS<imp-def>; GR64:%vreg9,%vreg8 JMP_4 <BB#1> Successors according to CFG: BB#1 BB#3 BB#3: derived from LLVM BB %entry Predecessors according to CFG: BB#1 BB#2 %EAX<def> = COPY %vreg4; GR32:%vreg4 RETQ %EAX<imp-use&gt...

...LEA64r %RSP, 1, %noreg, 40, %noreg %EDX<def> = MOV32r0 %EFLAGS<imp-def,dead> CALL64pcrel32 <ga:@dummy_use>, <regmask>, %RSP<imp-use>, %RCX<imp-use>, %EDX<imp-use,kill>, %RSP<imp-def> SEH_Epilogue %RSP<def,tied1> = ADD64ri32 %RSP<tied0>, 40040, %EFLAGS<imp-def,dead> RETQ # End machine code for function test_large. *** Bad machine code: Using an undefined physical register *** - function: test_large - basic block: BB#1 (0x40b1d70) - instruction: OR64mi8- operand 0: %RCX *** Bad machine code:...

...OV64rr %reg1228<kill> > 316 %reg1053 = MOV64rr %reg1229<kill> > 320 %reg1054 = MOV64rr %reg1230<kill> > 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 > 328 %reg1135 = MOVSX64rr32 %reg1025 > 332 %reg1136 = MOV64rr %reg1135<kill> > 336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead> > 340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def> > 344 JNS mbb<file solve.f, line 23, in loop at depth 1, > bb16,0x83a2c70>, > %EFLAGS<imp-use,kill> > > Here we have the curious case of %reg1055 being def...

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

Hi all, I changed the code that checks whether a tail call is really eligible for optimization so that it performs the check/fix in SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also eliminated an error that caused the remaining failing test cases in the test-suite. The results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

On Tue, 25 Sep 2007, Evan Cheng wrote: >> the stack adjustment only fastcc was not one of them. Now that fastcc >> can cause tail call optimization i had to change the convention from >> caller pops arguments to callee pops arguments in order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately

...MachineBasicBlock &MBB, + unsigned StackPtr) { + int32_t Offset = 0; + if (MBBI != MBB.begin()) { + MachineBasicBlock::iterator PI = prior(MBBI); + unsigned Opc = PI->getOpcode(); + if ((Opc == X86::ADD64ri32 || Opc == X86::ADD64ri8 || + Opc == X86::ADD32ri || Opc == X86::ADD32ri8) && + PI->getOperand(0).getReg() == StackPtr){ + Offset += PI->getOperand(2).getImm(); + MBB.erase(PI); + } + } + return Offset; +} + Seems like the previous chunk can be changed to...