Assertion Failure ScalarEvolutionExpander.cpp:80: `SE.DT.dominates(Ret, &*BIP)' failed #42270
Description
| Bugzilla Link | 42925 |
| Version | trunk |
| OS | All |
| Blocks | #44654 |
| Attachments | reduced test-case |
| CC | @berolinux,@fhahn,@zmodem,@tstellar,@yuanfang-chen |
Extended Description
The attached test-case hits an assertion failure in Induction Variable
Simplification, when optimized at -O1:
$ opt -O1 test.ll -S -o -
opt: ..../llvm/lib/Analysis/ScalarEvolutionExpander.cpp:80:
llvm::Value* llvm::SCEVExpander::ReuseOrCreateCast(
llvm::Value*, llvm::Type*, llvm::Instruction::CastOps,
llvm::BasicBlock::iterator):
Assertion `SE.DT.dominates(Ret, &*BIP)' failed.
Stack dump:
0. Program arguments: opt -O1 test.ll -S -o -
- Running pass 'CallGraph Pass Manager' on module 'test.ll'.
- Running pass 'Loop Pass Manager' on function '@foo'
- Running pass 'Induction Variable Simplification' on basic block '%do.body'
...
$
Bisecting shows that this problem first appeared with r320700, although that's
a valid commit, and it's clear that it just exposed a bug that was latent. It
still happens with ToT (tested with r368100).
FTR, the IR of the test-case contains code that clearly would deref a nullptr
at run-time if it were to be executed. Specifically, it contains:
define void @foo(i8* %arg) {
entry:
%stack_var = alloca i32, align 4
br label %do.body
do.body: ; preds = %do.body, %entry
%tmp3.0 = phi i32 [ 0, %entry ], [ %tmp2, %do.body ]
%tmp4.0 = phi i8* [ null, %entry ], [ %add.ptr, %do.body ]
%tmp1 = load i8, i8* %tmp4.0, align 1
...
}
I haven't been able to come up with a crashing test-case that's "clean" (in the
sense it does not have this nullptr deref problem). So maybe it's rooted in
that. For reference, the original test-case prior to reducing, had a formal
argument feeding into that PHI node in the definition of the full function,
rather than an explicit null. The problem as reported by the customer only
happened when LTO was on, and cross-module inlining exposed it. I tried
analyzing the callers in the original bitcode, to see whether I could determine
if a nullptr could be deduced to reach a call-site (and so there would be
Undefined Behavior at run-time), but I wasn't able to figure that out. My
guess is that that's what's happening. Regardless, of course a compile-time
crash isn't how we want to handle Undefined Behavior.