Displaying 11 results from an estimated 11 matches for "xx_stack".
Did you mean:
fix_stack
2012 Jun 14
1
[LLVMdev] Assert in live update from MI scheduler.
...on bug, not a DAG builder bug. Liveness will also have problems with this code in the long run.
To avoid confusion, I filed PR13112: Phi elimination generates uninitialized vreg uses, and disabled the SSA check until its fixes in r158461.
However, your C code is also fishy. I'm not sure what xx_stack is. In the machine code, if you only execute the loop body once, never taking the backedge, then you load from a garbage pointer after exiting the loop. I think you're saying that's intended behavior, which is fine. Just thought I would point it out.
-Andy
On Jun 13, 2012, at 3:25 PM, Ser...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
Ok, after 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 S...
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
...ks 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> = PH...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...re 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 %vreg5, <BB#0>,...
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.
...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>, 0; mem:LD4[%st...
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...om
> 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...
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.
...t;' 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 %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.
...> > 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,%vreg...