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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_live.o.ll
Type: application/octet-stream
Size: 2706 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120612/4c78b2fa/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_live.i
Type: application/octet-stream
Size: 639 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120612/4c78b2fa/attachment-0001.obj>
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 at 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
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 at 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