[LLVMdev] Assert in live update from MI scheduler.

[Sergei Larin]

Andy, 

  Thanks for reply. I was able to trace the problem to the MI DAG dep
constructor. See this:

SU(0):   %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10
  # preds left       : 0
  # succs left       : 0
  # rdefs left       : 1
  Latency            : 1
  Depth              : 0
  Height             : 0

SU(1):   %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.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) is missing, so when scheduler decides
to reorder them, LI rightfully complains.
Again, this is branch code, but if I can see something wrong in platform
independent portion, I'll track it on the trunk.

Thanks.

Sergei

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.


> -----Original Message-----
> From: Andrew Trick [mailto:atrick at apple.com]
> Sent: Tuesday, June 12, 2012 10:21 PM
> To: Sergei Larin
> Cc: llvmdev at cs.uiuc.edu List; Lang Hames
> Subject: Re: [LLVMdev] Assert in live update from MI scheduler.
> 
> 
> On Jun 12, 2012, at 10:22 AM, Sergei Larin <slarin at codeaurora.org>
> wrote:
> 
> >
> > Hello everyone,
> >
> >  I am working on a release based on the branch 3.1 version of code.
> > Unfortunately it has enough differences that exact rev does not
> apply.
> > I am hitting an assert in liveness update with seemingly trivial code
> > (attached).
> >
> > /local/mnt/workspace/slarin/tools/llvm-mainline-
> merged/lib/CodeGen/Liv
> > eInter
> > valAnalysis.cpp:1078: void
> > llvm::LiveIntervals::HMEditor::moveAllRangesFrom(llvm::MachineInstr*,
> > llvm::SlotIndex): Assertion `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>, 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> = 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[%stack.0.in]
> > IntRegs:%vreg10,%vreg9
> >
> > To be scheduled first (!). Right there after
> >
> > 7  clang           0x000000000226aece
> > llvm::LiveIntervals::handleMove(llvm::MachineInstr*) + 378
> > 8  clang           0x0000000001c2574f
> > llvm::VLIWMachineScheduler::listScheduleTopDown() + 595
> > 9  clang           0x0000000001c24cd5
> llvm::VLIWMachineScheduler::schedule()
> > + 505
> >
> > It does not seem to happen on the trunk.
> >
> > My question is - Does anyone recognizes the issue, and what patch(es)
> > do I need to address it. Since my release is based on 3.1, I have to
> > cherry pick them...
> > Any lead is highly appreciated.
> >
> > Thanks.
> >
> > Sergei
> >
> 
> Quickly scanning the commit log, I only see this one since 3.1:
> 
> commit f905f69668e5dd184c0a2b5fae38d9f3721c0d3b
> Author: Lang Hames <lhames at gmail.com>
> Date:   Tue May 29 18:19:54 2012 +0000
> 
>     Clear the entering, exiting and internal ranges of a bundle before
> collecting
>     ranges for the instruction about to be bundled. This fixes a bug in
> an external
>     project where an assertion was triggered due to spurious 'multiple
> defs' within
>     the bundle.
> 
>     Patch by Ivan Llopard. Thanks Ivan!
> 
> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157632
> 
> Maybe Lang can remember something relevant though.
> 
> I still see a number of these asserts on trunk. I just haven't gotten
> around to making a push to fix them yet, because I've been focussing on
> other areas. However, if you reproduce your problem on trunk, file a
> bug right away. If you aren't able to work around this, I'll take some
> time to file bugs for asserts that I can reproduce in case they're
> related to your problem.
> 
> -Andy