MemorySSA crashing with Assertion `!MSSA.isLiveOnEntryDef(MA) && "Hit liveOnEntry before clobber?"' failed.

[Quuxplusone]

Bugzilla Link	PR45976
Status	RESOLVED FIXED
Importance	P enhancement
Reported by	Mikael Holmén (mikael.holmen@ericsson.com)
Reported on	2020-05-18 06:11:22 -0700
Last modified on	2020-10-21 03:56:55 -0700
Version	trunk
Hardware	PC Linux
CC	alina.sbirlea@gmail.com, florian_hahn@apple.com, llvm-bugs@lists.llvm.org, paulsson@linux.vnet.ibm.com
Fixed by commit(s)
Attachments	bbi-42991.ll (663 bytes, text/plain) tc_mssa_liveonentry.ll (22125 bytes, text/plain)
Blocks
Blocked by
See also

Created attachment 23503
bbi-42991.ll reproducer

llvm commit: 87b235db63a3

If I compile with EXPENSIVE_CHECKS turned on and then run

 opt -S -o - bbi-42991.ll -early-cse-memssa

I hit the following assertion:

opt: ../lib/Analysis/MemorySSA.cpp:447: void checkClobberSanity(const
llvm::MemoryAccess *, llvm::MemoryAccess *, const llvm::MemoryLocation &, const
llvm::MemorySSA &, const (anonymous namespace)::UpwardsMemoryQuery &,
AliasAnalysisType &, bool) [AliasAnalysisType = llvm::AAResults]: Assertion
`!MSSA.isLiveOnEntryDef(MA) && "Hit liveOnEntry before clobber?"' failed.

[Quuxplusone]

Attached bbi-42991.ll (663 bytes, text/plain): bbi-42991.ll reproducer

[Quuxplusone]

Note that the input contains a basic block that is unreachable from entry, but
which branches to basic blocks that are in turn reachable from entry:

target triple = "x86_64-unknown-linux-gnu"

@c = external global i16, align 1
@d = external global i16, align 1

define void @e() {
bb.0:
  %0 = load i16, i16* @c, align 1
  br label %bb.1

bb.1:                                             ; preds = %bb.0, %bb.3
  br i1 undef, label %bb.3, label %bb.2

bb.2:                                             ; preds = %bb.1
  store i16 undef, i16* @d, align 1
  br label %bb.3

bb.3:                                             ; preds = %bb.1, %bb.2, %bb.4
  store i16 %0, i16* @c, align 1
  br label %bb.1

bb.4:                                             ; preds = %bb.4
  br i1 undef, label %bb.3, label %bb.4
}

Perhaps it's bb.4 that is causing problems?

[Quuxplusone]

When it fails we have:

(gdb) where
#0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff6673801 in __GI_abort () at abort.c:79
#2  0x00007ffff666339a in __assert_fail_base (fmt=0x7ffff67ea7d8 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x156672d
"!MSSA.isLiveOnEntryDef(MA) && \"Hit liveOnEntry before clobber?\"",
file=file@entry=0x12bc4f0 "../lib/Analysis/MemorySSA.cpp",
line=line@entry=0x1bf, function=function@entry=0x16c1dfe "void
checkClobberSanity(const llvm::MemoryAccess *, llvm::MemoryAccess *, const
llvm::MemoryLocation &, const llvm::MemorySSA &, const (anonymous
namespace)::UpwardsMemoryQuery &, AliasAnalysisType &, bool) [AliasAnalysisType
= llvm::AAResults]") at assert.c:92
#3  0x00007ffff6663412 in __GI___assert_fail (assertion=0x156672d
"!MSSA.isLiveOnEntryDef(MA) && \"Hit liveOnEntry before clobber?\"",
file=0x12bc4f0 "../lib/Analysis/MemorySSA.cpp", line=0x1bf, function=0x16c1dfe
"void checkClobberSanity(const llvm::MemoryAccess *, llvm::MemoryAccess *,
const llvm::MemoryLocation &, const llvm::MemorySSA &, const (anonymous
namespace)::UpwardsMemoryQuery &, AliasAnalysisType &, bool) [AliasAnalysisType
= llvm::AAResults]") at assert.c:101
#4  0x00000000054e1fb5 in checkClobberSanity<llvm::AAResults> (Start=0x7ea2408,
ClobberAt=0x7ea2488, StartLoc=..., MSSA=..., Query=..., AA=...,
AllowImpreciseClobber=0x0) at ../lib/Analysis/MemorySSA.cpp:447
#5  0x00000000054e0c78 in (anonymous
namespace)::ClobberWalker<llvm::AAResults>::findClobber (this=0x7ea2680,
Start=0x7ea2408, Q=..., UpWalkLimit=@0x7fffffffba1c: 0x62) at
../lib/Analysis/MemorySSA.cpp:965
#6  0x00000000054fec03 in
llvm::MemorySSA::ClobberWalkerBase<llvm::AAResults>::getClobberingMemoryAccessBase
(this=0x7ea2680, MA=0x7ea0d70, UpwardWalkLimit=@0x7fffffffba1c: 0x62,
SkipSelf=0x0) at ../lib/Analysis/MemorySSA.cpp:2407
#7  0x00000000054fe9bb in
llvm::MemorySSA::CachingWalker<llvm::AAResults>::getClobberingMemoryAccess
(this=0x7ea2460, MA=0x7ea0d70, UWL=@0x7fffffffba1c: 0x62) at
../lib/Analysis/MemorySSA.cpp:1026
#8  0x00000000054fe8f1 in
llvm::MemorySSA::CachingWalker<llvm::AAResults>::getClobberingMemoryAccess
(this=0x7ea2460, MA=0x7ea0d70) at ../lib/Analysis/MemorySSA.cpp:1036
#9  0x00000000066b2c8d in llvm::MemorySSAWalker::getClobberingMemoryAccess
(this=0x7ea2460, I=0x7e48910) at ../include/llvm/Analysis/MemorySSA.h:1026
#10 0x00000000066a7157 in (anonymous namespace)::EarlyCSE::isSameMemGeneration
(this=0x7fffffffc150, EarlierGeneration=0x1, LaterGeneration=0x3,
EarlierInst=0x7eb5dc0, LaterInst=0x7e48910) at
../lib/Transforms/Scalar/EarlyCSE.cpp:825
#11 0x00000000066a4b52 in (anonymous namespace)::EarlyCSE::processNode
(this=0x7fffffffc150, Node=0x7ea1360) at
../lib/Transforms/Scalar/EarlyCSE.cpp:1222
#12 0x00000000066a1b28 in (anonymous namespace)::EarlyCSE::run
(this=0x7fffffffc150) at ../lib/Transforms/Scalar/EarlyCSE.cpp:1343
#13 0x00000000066ae59b in (anonymous
namespace)::EarlyCSELegacyCommonPass<true>::runOnFunction (this=0x7e9c330,
F=...) at ../lib/Transforms/Scalar/EarlyCSE.cpp:1420
#14 0x0000000005fa0249 in llvm::FPPassManager::runOnFunction (this=0x7e9c7b0,
F=...) at ../lib/IR/LegacyPassManager.cpp:1482
#15 0x0000000005fa0655 in llvm::FPPassManager::runOnModule (this=0x7e9c7b0,
M=...) at ../lib/IR/LegacyPassManager.cpp:1518
#16 0x0000000005fa0db8 in (anonymous namespace)::MPPassManager::runOnModule
(this=0x7eb8620, M=...) at ../lib/IR/LegacyPassManager.cpp:1583
#17 0x0000000005fa08e5 in llvm::legacy::PassManagerImpl::run (this=0x7eb8190,
M=...) at ../lib/IR/LegacyPassManager.cpp:1695
#18 0x0000000005fa1341 in llvm::legacy::PassManager::run (this=0x7fffffffd018,
M=...) at ../lib/IR/LegacyPassManager.cpp:1726
#19 0x0000000003883cf7 in main (argc=0x6, argv=0x7fffffffd828) at
../tools/opt/opt.cpp:978

with

(gdb) p MSSA.dump()
define void @e() {
bb.0:
; MemoryUse(liveOnEntry) MayAlias
  %0 = load i16, i16* @c, align 1
  br label %bb.1

bb.1:                                             ; preds = %bb.3, %bb.0
; 4 = MemoryPhi({bb.0,liveOnEntry},{bb.3,2})
  br i1 undef, label %bb.3, label %bb.2

bb.2:                                             ; preds = %bb.1
; 1 = MemoryDef(4)
  store i16 undef, i16* @d, align 1
  br label %bb.3

bb.3:                                             ; preds = %bb.4, %bb.2, %bb.1
; 3 = MemoryPhi({bb.1,4},{bb.2,1},{bb.4,liveOnEntry})
; 2 = MemoryDef(3)
  store i16 %0, i16* @c, align 1
  br label %bb.1

bb.4:                                             ; preds = %bb.4
  br i1 undef, label %bb.3, label %bb.4
}

(gdb) p Start->dump()
3 = MemoryPhi({bb.1,4},{bb.2,1},{bb.4,liveOnEntry})

(gdb) p ClobberAt->dump()
4 = MemoryPhi({bb.0,liveOnEntry},{bb.3,2})

(gdb) p MA->dump()
0 = MemoryDef(liveOnEntry)

[Quuxplusone]

Ok, so checkClobberSanity starts with

3 = MemoryPhi({bb.1,4},{bb.2,1},{bb.4,liveOnEntry})

and since it's a MemoryPhi

when then end up with

      Worklist.append(
          upward_defs_begin({const_cast<MemoryAccess *>(MA), MAP.second},
                            MSSA.getDomTree()),
          upward_defs_end());

and here the {bb.4,liveOnEntry} entry in the PHI will make
 0 = MemoryDef(liveOnEntry)
(which seems to be connected to bb.0) end up in the Worklist since there is no
def in bb.4.

Then when we analyse
 0 = MemoryDef(liveOnEntry)
the assertion fails.

However, since bb.4 isn't reachable from entry I suppose we don't really want
to add
 0 = MemoryDef(liveOnEntry)
to the Worklist here? I'm not sure how to accomplish that though since that is
what upward_defs_iterator will give us.

[Quuxplusone]

Attached tc_mssa_liveonentry.ll (22125 bytes, text/plain): Reduced SystemZ test case

[Quuxplusone]

This should be fixed by dc971381235. Please reopen if needed.

[Quuxplusone]

(In reply to Alina Sbirlea from comment #5)
> This should be fixed by dc971381235. Please reopen if needed.

Thanks!