search for: add_ri

...ementation 1 would be the most elegant one. It would have a one to one correspondence with the ARM Architecture Reference Model. For two to work it would be necessary to write custom select code to use the more uncommon addressing options. For three I could use the multiclass feature to implement add_ri and add_rr. The add_ri instruction would use a custom addressing mode for the second operand. Currently I am planning to implement 3 because it looks like to be the easiest to implement. Any comments? Thanks, Rafael

...lt;BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 > %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 > %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 > %vreg3<def> = ADD_ri %vreg2, 8; IntRegs:%vreg3,%vreg2 > %vreg6<def> = CMPEQri %vreg2, 0; PredRegs:%vreg6 IntRegs:%vreg2 > JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 > JMP <BB#2> > Successors according to CFG: BB#2 BB#1 > > BB#2: derived...

...to CFG: BB#0 BB#1 %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 <<<<<<<<<<<<< First use uninitialized vreg10 %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg10,%vreg9 %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 %vreg6<def> = CMPEQri %vreg10, 0; PredRegs:%vreg6 IntRegs:%vreg10 JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 JMP <BB#2> Successors according to CFG: BB#2 BB#1 BB#2: derived from LLVM BB %for.e...

...BB#1 > %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 <<<<<<<<<<<<< First use uninitialized vreg10 > %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg10,%vreg9 > %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 > %vreg6<def> = CMPEQri %vreg10, 0; PredRegs:%vreg6 IntRegs:%vreg10 > JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 > JMP <BB#2> > Successors according to CFG: BB#2 BB#1 > > BB#2: der...

...egant one. It > would have a one to one correspondence with the ARM Architecture > Reference Model. > > For two to work it would be necessary to write custom select code to > use the more uncommon addressing options. > > For three I could use the multiclass feature to implement add_ri and > add_rr. The add_ri instruction would use a custom addressing mode for > the second operand. > > Currently I am planning to implement 3 because it looks like to be the > easiest to implement. I'm not sure exactly what the constraints you have are, but I'd suggest using...

...HI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 %vreg3<def> = ADD_ri %vreg2, 8; IntRegs:%vreg3,%vreg2 %vreg6<def> = CMPEQri %vreg2, 0; PredRegs:%vreg6 IntRegs:%vreg2 JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 JMP <BB#2> Successors according to CFG: BB#2 BB#1 BB#2: derived from LLVM BB %for.end...

...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>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg10,%vreg9 112B %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 128B %vreg6<def> = CMPEQri %vreg10, 0; PredRegs:%vreg6 IntRegs:%vreg10 176B JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 192B JMP <BB#2> Successors according to CFG: BB#2 BB#1 208B BB#2: derived fr...

...m 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>, 0; mem:LD4[%stack.0.in] > IntRegs:%vreg10,%vreg9 > 112B %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 > 128B %vreg6<def> = CMPEQri %vreg10, 0; PredRegs:%vreg6 IntRegs:%vreg10 > 176B JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 > 192B JMP <BB#2> > Successors according to CFG: BB#2 BB#1 >...

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

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

...tack.0.in] IntRegs:%vreg10,%vreg9 # preds left : 0 # succs left : 3 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 Successors: val SU(3): Latency=1 val SU(2): Latency=1 antiSU(2): Latency=0 SU(2): %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 # preds left : 2 # succs left : 0 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 Predecessors: val SU(1): Latency=1 Reg=%vreg10 antiSU(1): Latency=0 The anti dep between SU(0) and SU(1)...

On Aug 1, 2012, at 1:53 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > > Currently, we rely on switch tables to transform between formats. However, > we would like to have a different mechanism to represent these relationships > instead of switch tables. I am thinking of modeling these relations in > HexagonInstrInfo.td file and use TableGen to generate a table with

...lt; IFormat TransformsFrom> { def #NAME# : V2_A2_add, RelationMap < TransformsFrom, Format_rr>; defm _pt : V2_A2_padd, RelationMap < Format_rr, Format_predt, ["rr"]>; defm _pf : V2_A2_padd, RelationMap < Format_rr, Format_predf, ["rr"] >; } multiclass Add_ri < IFormat TransformsFrom> { def #NAME# : V2_A2_addi, RelationMap < TransformsFrom, Format_ri >; defm _pt : V2_A2_paddi, RelationMap < Format_ri, Format_predt, ["ri"] >; defm _pf : V2_A2_paddi, RelationMap < Format_ri, Format_predf, ["ri"] >; } mul...

Hi, I'm looking for some suggestions on a problem related to the Hexagon backend. Hexagon architecture allows instructions in various formats. For example, we have 3 variations of the add instruction as defined below: ADDrr : r1 = add(r2, r3) --> add 2 32-bit registers ADDrr_p : if(p0) r1 = add(r2, r3) --> predicated version of ADDrr instruction, executed when p0 is true ADDrr_np :

...: 0 > # succs left : 3 > # rdefs left : 1 > Latency : 1 > Depth : 0 > Height : 0 > Successors: > val SU(3): Latency=1 > val SU(2): Latency=1 > antiSU(2): Latency=0 > > SU(2): %vreg9<def> = ADD_ri %vreg10, 8; IntRegs:%vreg9,%vreg10 > # preds left : 2 > # succs left : 0 > # rdefs left : 1 > Latency : 1 > Depth : 0 > Height : 0 > Predecessors: > val SU(1): Latency=1 Reg=%vreg10 > antiSU(1): Lat...

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

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