search for: jmpr

...y pointer") IntRegs:%vreg7,%vreg1 > STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 > %vreg8<def> = IMPLICIT_DEF; IntRegs:%vreg8 > %R0<def> = COPY %vreg8<kill>; IntRegs:%vreg8 > JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,kill> > > Right after the dead vreg is introduced: > > # *** IR Dump After Eliminate PHI nodes for register allocation ***: > # Machine code for function push: Post SSA > Function Live Outs: %R0 > > BB#0: deriv...

...r.end Predecessors according to CFG: BB#1 %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any pointer") IntRegs:%vreg7,%vreg1 STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef> If loop never iterates, vreg10 and vreg1 will hold garbage (as they should!). If it iterates even once, vreg1 use in BB2 will be fine. This exactly matches original C code behavior. If it is a legitimate code sequence, we n...

...redecessors according to CFG: BB#1 > %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any pointer") IntRegs:%vreg7,%vreg1 > STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 > JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef> > > If loop never iterates, vreg10 and vreg1 will hold garbage (as they should!). If it iterates even once, vreg1 use in BB2 will be fine. > This exactly matches original C code behavior. > > If it is a legitimate...

...invalidated by the restored callee saved registers. ... movl 12(%esp), %esi << 12(%esp) contains the function pointer movl %eax, 44(%esp) movl 32(%esp), %esi << *!# %esi no longer contains the function pointer to be called addl $44, %esp jmp *%esi # TAIL CALL jmpr Is there a way to indicate that the register the tail call instruction uses as destination needs to be valid after the callee saved registers have been restored? (some X86InstrInfo.td foo magic maybe ?) Or do i have to insert code into PEI::saveCalleeSavedRegisters to detect that there is...

...](tbaa=!"any pointer") IntRegs:%vreg7,%vreg1 STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 %vreg8<def> = IMPLICIT_DEF; IntRegs:%vreg8 %R0<def> = COPY %vreg8<kill>; IntRegs:%vreg8 JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,kill> Right after the dead vreg is introduced: # *** IR Dump After Eliminate PHI nodes for register allocation ***: # Machine code for function push: Post SSA Function Live Outs: %R0 BB#0: derived from LLVM BB %entry %vre...

On Jun 13, 2012, at 10:49 AM, Sergei Larin <slarin at codeaurora.org> wrote: > So if this early exit is taken: > > // SSA defs do not have output/anti dependencies. > // The current operand is a def, so we have at least one. > if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) > return; > > we do not ever get to this point: > >

...Predecessors according to CFG: BB#1 224B %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any pointer") IntRegs:%vreg7,%vreg1 240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 256B JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef> Hexagon MI scheduler is working with BB1 and picks this load: %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg10,%vreg9 To be scheduled first (!). Right there after 7 clang 0x0000...

...to CFG: BB#1 > 224B %vreg7<def> = LDriw %vreg1<kill>, 0; mem:LD4[%first1](tbaa=!"any > pointer") IntRegs:%vreg7,%vreg1 > 240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; > mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 > 256B JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef> > > Hexagon MI scheduler is working with BB1 and picks this load: > > %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] > IntRegs:%vreg10,%vreg9 > > To be scheduled first (!). Right there...

...the function pointer to (right before the callee saved register restore) but thinking a little further that's nonsense. something like let isCall = 1, isTerminator = 1, isReturn = 1, isBarrier = 1, noResults = 1, ifDestRegisterisCalleeSavedEmitAMoveToECXAndJumpToThat=1 in def TAILJMPr : I<0xFF, MRM4r, (ops GR32:$dst), "jmp {*}$dst # TAIL CALL jmpr", []>; On 8 Aug 2007, at 18:27, Dale Johannesen wrote: > Inserting a pseudo before your tail call that defines all the callee- > saved > registers should work. See FP_REG_KILL. the trick...

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

On Jun 11, 2012, at 12:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Looking at VLIWPacketizerList::PacketizeMIs, it seems like the > instructions are first scheduled (via some external scheme?), and then > packetized 'in order'. Is that correct? Anshu? > In the PowerPC grouping scheme, resources are assigned on a group > basis (by the instruction dispatching

...efore the callee saved register restore) but thinking a little > further that's nonsense. > > something like > let isCall = 1, isTerminator = 1, isReturn = 1, isBarrier = 1, > noResults = 1, > ifDestRegisterisCalleeSavedEmitAMoveToECXAndJumpToThat=1 > in > def TAILJMPr : I<0xFF, MRM4r, (ops GR32:$dst), "jmp {*}$dst # > TAIL CALL jmpr", > []>; > > On 8 Aug 2007, at 18:27, Dale Johannesen wrote: >> Inserting a pseudo before your tail call that defines all the callee- >> saved >> registers should work....

...%vreg7<def> = LDriw %vreg1<kill>, 0; > mem:LD4[%first1](tbaa=!"any > > pointer") IntRegs:%vreg7,%vreg1 > > 240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; > > mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 > > 256B JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef> > > > > Hexagon MI scheduler is working with BB1 and picks this load: > > > > %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] > > IntRegs:%vreg10,%vreg9 > > > > To be...

On Mon, 11 Jun 2012 10:48:18 -0700 Andrew Trick <atrick at apple.com> wrote: > On Jun 11, 2012, at 9:30 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > I'm considering writing more-detailed itineraries for some PowerPC > > CPUs that use the 'traditional' instruction grouping scheme. In > > essence, this means that multiple instructions will stall

...w %vreg1<kill>, 0; > > mem:LD4[%first1](tbaa=!"any > > > pointer") IntRegs:%vreg7,%vreg1 > > > 240B STriw_GP <ga:@yy_instr>, 0, %vreg7<kill>; > > > mem:ST4[@yy_instr](tbaa=!"any pointer") IntRegs:%vreg7 > > > 256B JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,undef> > > > > > > Hexagon MI scheduler is working with BB1 and picks this load: > > > > > > %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] > > > IntRegs:%vreg10,%vreg9 &...

...gt;>> IntRegs:%vreg1,%vreg9 >>>>> Successors according to CFG: BB#8 >>>>> >>>>> BB#8: derived from LLVM BB %sw.epilog, ADDRESS TAKEN >>>>> Predecessors according to CFG: BB#0 BB#1 BB#7 BB#6 BB#5 BB#4 BB#2 >>>>> JMPR %PC<imp-def,dead>, %R31<imp-use>, %R0<imp-use,undef> >>>>> ... >>>>> >>>>> BB#7 seems to cause a problem when iterating over it with RegionEnd >>>> pointing >>>>> somewhere wrong. Am I breaking some implicit...