search for: predregs

...lt;(outs DoubleRegs:$dst, IntRegs:$dst2), >> >> // Load doubleword conditionally. >> let mayLoad = 1, neverHasSideEffects = 1 in >> -def LDrid_cPt : LDInst<(outs DoubleRegs:$dst), >> +def LDrid_cPt : LDInst2<(outs DoubleRegs:$dst), >> (ins PredRegs:$src1, MEMri:$addr), >> "if ($src1) $dst = memd($addr)", >> []>; >> >> >> let mayLoad = 1, neverHasSideEffects = 1 in >> -def LDrid_cNotPt : LDInst<(outs DoubleRegs:$dst), >> +def LDrid_cNotPt : LDInst2<(outs...

...gt;, pred:%noreg; IntRegs:%vreg8 dbg:../src/getbits.c:46:1 64B %vreg9<def> = LDUBri %vreg8, 1, pred:%noreg; mem:LD1[getelementptr inbounds (%struct.FIFO* @fifo, i32 0, i32 1)] IntRegs:%vreg9,%vreg8 dbg:../src/getbits.c:46:1 80B %vreg10<def> = CMPEQI %vreg9<kill>, 0, pred:%noreg; PredRegs:%vreg10 IntRegs:%vreg9 dbg:../src/getbits.c:46:1 96B JUMP <BB#2>, pred:%vreg10<kill>; PredRegs:%vreg10 Successors according to CFG: BB#2(12) BB#1(20) 112B BB#1: Predecessors according to CFG: BB#0 128B %vreg27<def> = MOV32ri -1, pred:%noreg; IntRegs:%vreg27 160B JUM...

...t; = 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 > Predecessors according to CFG: BB#1 > %vreg7<def...

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

...eg10 <<<<<<<<<<<<< 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.end Predecessors according to CFG: BB#1 %vreg7<def> = LDriw %vreg1<kill...

...;<<<<<<<<<<< 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.end > Predecessors according to CFG: BB#1 > %vreg7<de...

...eg1<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 Predecessors according to CFG: BB#1 %vreg7<def> = LDriw %vreg1<kill&...

...ntioned, the problem is linked to the fact that type legalization happens before register class assignments. One way to solve this problem would be to teach type legalization about the predicate register class: if a processor can perform only boolean arithmetic it would declare a type to be in the PredRegs class, whereas a processor that can do both integer and boolean arithmetic on a type would declare the register to be in both the IntRegs and PredRegs class, or just in the IntRegs class. Opinions? How hard is it to teach type legalization about register classes? Thanks, Sebastian -- Qualcomm In...

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

...inked to the fact that type > legalization happens before register class assignments. > > One way to solve this problem would be to teach type legalization > about the predicate register class: if a processor can perform only > boolean arithmetic it would declare a type to be in the PredRegs > class, whereas a processor that can do both integer and boolean > arithmetic on a type would declare the register to be in both the > IntRegs and PredRegs class, or just in the IntRegs class. > > Opinions? How hard is it to teach type legalization about register > classes? &gt...

...%6:intregs, %bb.5, %4:intregs, %bb.3 %13:intregs, %4:intregs = L2_loadri_pi %2:intregs(tied-def 1), 4 :: (load 4 from %ir.a.addr.03, !tbaa !2) %5:intregs = S2_storeri_pi %1:intregs(tied-def 0), 4, %13:intregs :: (store 4 into %ir.res.addr.04, !tbaa !2) %3:intregs = A2_addi %0:intregs, 1 %14:predregs = C2_cmpgtu %0:intregs, %3:intregs J2_jumpf %14:predregs, %bb.3, implicit-def dead $pc J2_jump %bb.4, implicit-def dead $pc The same code on LLVM 7 is this: bb.2.while.body.preheader: ; predecessors: %bb.1 successors: %bb.4(0x80000000); %bb.4(200.00%) %11:intregs = A2_tfrsi -100 J2_ju...

...#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 from LLVM BB %for.end Predecessors according to CFG: BB#1 224B %vreg7<def> =...

On Sun, Jun 3, 2012 at 7:11 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: >> So the solution that I was investigating looks like this: >> >>      for (unsigned int i = 0; i<  ISD::BUILTIN_OP_END; ++i) { >>        switch (i) { >>        // By default all operations on i8 have to be promoted to i32. >>        default: >>        

Hi Pranav, >> as well as what Eli said, ReplaceNodeResults requires (IIRC) the new node > to >> have the same type as the old node, which doesn't seem to be the case >> here. > > Are you sure ? I see ReplaceNodeResults being called from functions such as > CustomWidenLowerNode and CustomLowerNode. > In the former, we are clearly expecting a change in type,

Hi Duncan, > as well as what Eli said, ReplaceNodeResults requires (IIRC) the new node to > have the same type as the old node, which doesn't seem to be the case > here. Are you sure ? I see ReplaceNodeResults being called from functions such as CustomWidenLowerNode and CustomLowerNode. In the former, we are clearly expecting a change in type, aren't we? Even in the latter,

...;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 from LLVM BB %for.end > Predecessors according to CFG: BB#1...

...%6:intregs, %bb.5, %4:intregs, %bb.3 %13:intregs, %4:intregs = L2_loadri_pi %2:intregs(tied-def 1), 4 :: (load 4 from %ir.a.addr.03, !tbaa !2) %5:intregs = S2_storeri_pi %1:intregs(tied-def 0), 4, %13:intregs :: (store 4 into %ir.res.addr.04, !tbaa !2) %3:intregs = A2_addi %0:intregs, 1 %14:predregs = C2_cmpgtu %0:intregs, %3:intregs J2_jumpf %14:predregs, %bb.3, implicit-def dead $pc J2_jump %bb.4, implicit-def dead $pc The same code on LLVM 7 is this: bb.2.while.body.preheader: ; predecessors: %bb.1 successors: %bb.4(0x80000000); %bb.4(200.00%) %11:intregs = A2_tfrsi -100 J2_...

...ry. I intend to create classes for each insn with the opcode and have the current insn definitions use the current names but based on a insn class. For example, a conditional indirect branch insn is currently defined as: def JMPR_cdnNotPt_V3: JRInst<(outs), (ins PredRegs:$src1, IntRegs:$src2), "if (!$src1.new) jumpr:t $src2", []>, Requires<[HasV3T]>; Its new definition would be like this: let Defs = [PC], isPredicated = 1 in class V3_J2_jumprfnewpt<list<dag...

Sorry, this is the part in ARMLoadStoreOptimizer.cpp that creates a LDRD instruction. Ops.pop_back(); Ops.pop_back(); // Form the pair instruction. if (isLd) { MachineInstrBuilder MIB = BuildMI(*MBB, InsertPos, dl, TII->get(NewOpc)) .addReg(EvenReg, RegState::Define)

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