Displaying 11 results from an estimated 11 matches for "yy_instr".
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
...>
> 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>, 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
> %vreg8<def> = IMPLICIT_DEF; IntRegs:%vreg8
> %R0<def> = COPY %vreg8<kill>; IntRegs:%vreg8
> JMPR %PC<imp-def>, %R31<imp-use>, %R0<imp-use,kill>
>...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...a long detour I am back to where I have started. I think there is
a problem at dep DAG construction. Let me try to convince you.
Here is the C code we are dealing with:
push ()
{
struct xx_stack *stack, *top;
for (stack = xx_stack; stack; stack = stack->next)
top = stack;
yy_instr = top->first;
}
If the loop never iterates, "top" will have garbage in it. If it iterates
even once, it will presumably have valid pointer. Bad, but perfectly valid
code.
In SSA it looked like this:
BB#0: derived from LLVM BB %entry
%vreg5<def> = IMPLICIT_DEF; Int...
2012 Jun 14
1
[LLVMdev] Assert in live update from MI scheduler.
...have started. I think there is a problem at dep DAG construction. Let me try to convince you…
>
> Here is the C code we are dealing with:
>
> push ()
> {
> struct xx_stack *stack, *top;
> for (stack = xx_stack; stack; stack = stack->next)
> top = stack;
> yy_instr = top->first;
> }
>
> If the loop never iterates, “top” will have garbage in it. If it iterates even once, it will presumably have valid pointer. Bad, but perfectly valid code.
>
> In SSA it looked like this:
> BB#0: derived from LLVM BB %entry
> %vreg5<def> =...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...%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>, 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
%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...
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
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:
>
>
2012 Jun 12
2
[LLVMdev] Assert in live update from MI scheduler.
...lt;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> = 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[%st...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...s 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> = 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 %vreg...
2012 Jun 11
0
[LLVMdev] scoreboard hazard det. and instruction groupings
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
2012 Jun 13
4
[LLVMdev] Assert in live update from MI scheduler.
...>
> > 208B BB#2: derived from LLVM BB %for.end
> > 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:
> >
> > %vre...
2012 Jun 11
3
[LLVMdev] scoreboard hazard det. and instruction groupings
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
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...B#2: derived from LLVM BB %for.end
> > > 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:
>...