search for: sub64ri32

...eSetup %RCX<def> = MOV64rr %RSP; flags: FrameSetup Successors according to CFG: BB#1 BB#1: derived from LLVM BB %0 Predecessors according to CFG: BB#0 BB#1 OR64mi8 %RCX, 1, %noreg, 0, %noreg, 0, %EFLAGS<imp-def>; flags: FrameSetup %RCX<def,tied1> = SUB64ri32 %RCX<tied0>, 4096, %EFLAGS<imp-def>; flags: FrameSetup %RDX<def,tied1> = SUB64ri32 %RDX<tied0>, 4096, %EFLAGS<imp-def>; flags: FrameSetup JAE_1 <BB#1>, %EFLAGS<imp-use>; flags: FrameSetup Successors according to CFG: BB#2 BB#1 BB#2: der...

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 >>

...// merge the two. This can be the case when tail call elimination is + // enabled and the callee has more arguments then the caller + if (MBBI != MBB.begin()) { + MachineBasicBlock::iterator PI = prior(MBBI); + unsigned Opc = PI->getOpcode(); + if ((Opc == X86::SUB64ri32 || Opc == X86::SUB64ri8 || + Opc == X86::SUB32ri || Opc == X86::SUB32ri8) && Weird indentation? +/// CheckAndDeletePreceedingADD - looks at instruction before the passed +/// instruction if it is an ADD instruction it is deleted and the size is +/// returned +static...

...the stack pointer, add it back. We do this until we have // more advanced stack pointer tracking ability. if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { unsigned Opc = (CalleeAmt < 128) ? (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); MachineInstr *New = BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm (CalleeAmt); MBB.insert(I, New); } } I am not sure about a command line switch would toggling the stack adjusting behaviour of a function. Because if the function is calle...

...ack. We do this > until we have > // more advanced stack pointer tracking ability. > if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { > unsigned Opc = (CalleeAmt < 128) ? > (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : > (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); > MachineInstr *New = > BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm > (CalleeAmt); > MBB.insert(I, New); > } > } > > I am not sure about a command line switch would toggling the stack > adjusting behaviour of a f...

...; until we have >> // more advanced stack pointer tracking ability. >> if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { >> unsigned Opc = (CalleeAmt < 128) ? >> (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : >> (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); >> MachineInstr *New = >> BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm >> (CalleeAmt); >> MBB.insert(I, New); >> } >> } >> >> I am not sure about a command line switch would toggling the stack...

On Tue, Mar 17, 2015 at 6:14 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> As a simplification, the compiler deals almost exclusively in pseudo >> instructions. By x86 analogy, using pseudos to unfold a TEST32rm into >> MOV32rm + TEST32rr means I can skip the complex operand fitting effort >> needed to pick specific machine instructions. There are many

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