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

[Carrot Wei via llvm-commits]

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