search for: tfri_v4

...on this code looks much more sane: > > # *** IR Dump After Live Variable Analysis ***: > # Machine code for function push: SSA > Function Live Outs: %R0 > > BB#0: derived from LLVM BB %entry > %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 > %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4 > Successors according to CFG: BB#1 > > BB#1: derived from LLVM BB %for.cond > Predecessors according to CFG: BB#0 BB#1 > %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 > %vreg...

...perfectly valid code. In SSA it looked like this: BB#0: derived from LLVM BB %entry %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<Dummy def. %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4 Successors according to CFG: BB#1 BB#1: derived from LLVM BB %for.cond Predecessors according to CFG: BB#0 BB#1 %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 %vreg1<def> = PHI %vreg...

...e. > > In SSA it looked like this: > BB#0: derived from LLVM BB %entry > %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<Dummy def. > %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4 > Successors according to CFG: BB#1 > > BB#1: derived from LLVM BB %for.cond > Predecessors according to CFG: BB#0 BB#1 > %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 > %vreg...

...k at this - before phi elimination this code looks much more sane: # *** IR Dump After Live Variable Analysis ***: # Machine code for function push: SSA Function Live Outs: %R0 BB#0: derived from LLVM BB %entry %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4 Successors according to CFG: BB#1 BB#1: derived from LLVM BB %for.cond Predecessors according to CFG: BB#0 BB#1 %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 %vreg1<def> = PHI %vreg...

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

...tion `validator.rangesOk() && "moveAllOperandsFrom broke liveness."' failed. The code being scheduled (function "push") is trivial: # Machine code for function push: Post SSA Function Live Outs: %R0 0B BB#0: derived from LLVM BB %entry 16B %vreg9<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg9 Successors according to CFG: BB#1 48B BB#1: derived from LLVM BB %for.cond Predecessors according to CFG: BB#0 BB#1 80B %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 96B %vreg10<def> = LDriw %vreg9<kill&gt...

...oveAllOperandsFrom > broke liveness."' failed. > > The code being scheduled (function "push") is trivial: > > # Machine code for function push: Post SSA > Function Live Outs: %R0 > > 0B BB#0: derived from LLVM BB %entry > 16B %vreg9<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg9 > Successors according to CFG: BB#1 > > 48B BB#1: derived from LLVM BB %for.cond > Predecessors according to CFG: BB#0 BB#1 > 80B %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 > 96B %vreg10<def&g...

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

...ke liveness."' failed. > > > > The code being scheduled (function "push") is trivial: > > > > # Machine code for function push: Post SSA Function Live Outs: %R0 > > > > 0B BB#0: derived from LLVM BB %entry > > 16B %vreg9<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg9 > > Successors according to CFG: BB#1 > > > > 48B BB#1: derived from LLVM BB %for.cond > > Predecessors according to CFG: BB#0 BB#1 > > 80B %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 >...

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

...; > > > > > The code being scheduled (function "push") is trivial: > > > > > > # Machine code for function push: Post SSA Function Live Outs: %R0 > > > > > > 0B BB#0: derived from LLVM BB %entry > > > 16B %vreg9<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg9 > > > Successors according to CFG: BB#1 > > > > > > 48B BB#1: derived from LLVM BB %for.cond > > > Predecessors according to CFG: BB#0 BB#1 > > > 80B %vreg1<def> = COPY %vreg10<kill>; Int...

...in >> +def : Pat<(i32 (zextloadi16 (HexagonCONST32 tglobaladdr:$absaddr))), >> + (LDriuh_abs_V4 tglobaladdr:$absaddr)>; >> + >> +// Transfer global address into a register >> +let AddedComplexity=50, isMoveImm = 1, isReMaterializable = 1 in >> +def TFRI_V4 : ALU32_ri<(outs IntRegs:$dst), (ins globaladdress:$src1), >> + "$dst = ##$src1", >> + [(set IntRegs:$dst, (HexagonCONST32 tglobaladdr:$src1))]>, >> + Requires<[HasV4T]>; >> + >> +let AddedComplexity=50, neverHasSideE...