[LLVMdev] Assert in live update from MI scheduler.

[Andrew Trick]

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/LiveInter
> 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