[llvm] r368339 - [MBP] Disable aggressive loop rotate in plain mode

Thu Aug 15 08:10:40 PDT 2019

So your patch just triggered the bug?  +David Blaikie.

David

On Thu, Aug 15, 2019 at 12:02 AM Carrot Wei via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> When function LiveDebugValues::ExtendRanges works on following MBB
>
> bb.62 (%ir-block.187):
> ; predecessors: %bb.61
>   successors: %bb.63(0x80000000); %bb.63(100.00%)
>   liveins: $edi, $edx
>   DBG_VALUE $edi, $noreg, !"range", !DIExpression(), debug-location !136
> 32; ../../v8\src/torque/utils.h:0 @[
> ../../v8/src/torque/csa-generator.cc:94 @[
> ../../v8/src/torque/csa-generator.cc:76 ] ] line no:263
>   DBG_VALUE $esi, 0, !"range", !DIExpression(DW_OP_LLVM_fragment, 0, 32)
> , debug-location !13632; ../../v8\src/torque/utils.h:0 @[ ../../v8/src/t
> orque/csa-generator.cc:94 @[ ../../v8/src/torque/csa-generator.cc:76 ] ]
>  line no:263 indirect
>   renamable $eax = MOV32rm $esi, 1, $noreg, 0, $noreg :: (load 4 from
> %stack.54)
>   MOV32mr $esi, 1, $noreg, 24, $noreg, killed renamable $edx :: (store 4
>  into %stack.56)
>   renamable $edx = MOV32rm $esi, 1, $noreg, 20, $noreg :: (load 4 from %
> stack.55)
>   renamable $eax = SHL32ri killed renamable $eax(tied-def 0), 2,
> implicit-def dead $eflags, debug-location !13658;
> ../../v8\src/torque/utils.h:2
> 66 @[ ../../v8/src/torque/csa-generator.cc:94 @[ ../../v8/src/torque/csa
> -generator.cc:76 ] ]
>   renamable $ebx = LEA32r killed renamable $eax, 2, renamable $eax, 0, $
> noreg, debug-location !13658; ../../v8\src/torque/utils.h:266 @[ ../../v
> 8/src/torque/csa-generator.cc:94 @[
> ../../v8/src/torque/csa-generator.cc:76 ] ]
>   renamable $eax = LEA32r $noreg, 4, killed renamable $edi, 0, $noreg, d
> ebug-location !13658; ../../v8\src/torque/utils.h:266 @[ ../../v8/src/to
> rque/csa-generator.cc:94 @[ ../../v8/src/torque/csa-generator.cc:76 ] ]
>   renamable $eax = LEA32r killed renamable $eax, 2, renamable $eax, 0, $
> noreg, debug-location !13658; ../../v8\src/torque/utils.h:266 @[
> ../../v8/src/torque/csa-generator.cc:94 @[
> ../../v8/src/torque/csa-generator.cc
> :76 ] ]
>   MOV32mr $esi, 1, $noreg, 0, $noreg, killed renamable $eax :: (store 4
> into %stack.54)
>
> The data structure OpenRanges got inconsistent internal state. Its
> field OpenRanges.Vars and OpenRanges.VarLocs should have same number
> of elements.
>
> Before handling the third instruction
>
> renamable $eax = MOV32rm $esi, 1, $noreg, 0, $noreg :: (load 4 from
> %stack.54)
>
> Both OpenRanges.Vars and OpenRanges.VarLocs have 2 elements. Then
> function insertTransferDebugPair is called, it calls OpenRanges.erase
> to delete 1 element from OpenRanges, then both OpenRanges.Vars and
> OpenRanges.VarLocs have 1 element. Later OpenRanges.insert is called
> for the new fragment, this function adds new element to
> OpenRanges.Vars and OpenRanges.VarLocs at the same time, but the
> SmallDenseMap OpenRanges.Vars already has the same key, so
> OpenRanges.Vars just replaced the old value with new one, it still has
> only 1 element, OpenRanges.VarLocs has 2 elements now. Later when
> elements are removed from OpenRanges.Vars, OpenRanges.VarLocs still
> contains 1 value, and caused the assertion failure in function
> OpenRanges.empty.
>
> I'm not familiar with debug information, could anybody help to give me a
> hint?
>
> thanks a lot!
>
> On Tue, Aug 13, 2019 at 10:45 PM Carrot Wei <carrot at google.com> wrote:
> >
> > I didn't know llvm on linux can cross build windows binary.
> > Now I can reproduce it.
> >
> > On Tue, Aug 13, 2019 at 12:21 AM Hans Wennborg <hans at chromium.org>
> wrote:
> > >
> > > Did you look at
> > > https://bugs.chromium.org/p/chromium/issues/detail?id=992871#c3 ? It
> > > shows how to reproduce using the tarball on Linux.
> > >
> > > On Mon, Aug 12, 2019 at 8:17 PM Carrot Wei <carrot at google.com> wrote:
> > > >
> > > > The MBP patch doesn't touch debug information, I suspect there is
> > > > something unrelated was triggered.
> > > > I tried your tarball, but found it is for windows, I don't have a
> > > > windows machine :(. Do you have a linux reproduce? It's even better
> to
> > > > have a compiler command line.
> > > >
> > > > On Mon, Aug 12, 2019 at 7:24 AM Hans Wennborg <hans at chromium.org>
> wrote:
> > > > >
> > > > > I've reverted this in r368579 since it causes asserts when building
> > > > > Chromium. See
> https://bugs.chromium.org/p/chromium/issues/detail?id=992871
> > > > > for details and reproducer.
> > > > >
> > > > > On Thu, Aug 8, 2019 at 10:24 PM Guozhi Wei via llvm-commits
> > > > > <llvm-commits at lists.llvm.org> wrote:
> > > > > >
> > > > > > Author: carrot
> > > > > > Date: Thu Aug  8 13:25:23 2019
> > > > > > New Revision: 368339
> > > > > >
> > > > > > URL: http://llvm.org/viewvc/llvm-project?rev=368339&view=rev
> > > > > > Log:
> > > > > > [MBP] Disable aggressive loop rotate in plain mode
> > > > > >
> > > > > > Patch https://reviews.llvm.org/D43256 introduced more
> aggressive loop layout optimization which depends on profile information.
> If profile information is not available, the statically estimated profile
> information(generated by BranchProbabilityInfo.cpp) is used. If user
> program doesn't behave as BranchProbabilityInfo.cpp expected, the layout
> may be worse.
> > > > > >
> > > > > > To be conservative this patch restores the original layout
> algorithm in plain mode. But user can still try the aggressive layout
> optimization with -force-precise-rotation-cost=true.
> > > > > >
> > > > > > Differential Revision: https://reviews.llvm.org/D65673
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190815/ad8b389a/attachment.html>