<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - [PM] Analysis invalidation when deleting IRUnitT's (in particular functions)"
href="https://llvm.org/bugs/show_bug.cgi?id=28400">28400</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[PM] Analysis invalidation when deleting IRUnitT's (in particular functions)
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Core LLVM classes
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>chisophugis@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Blocks</th>
<td>28315
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Below is a test case where globaldce deletes a function even though
LazyValueInfo still has an AssertingVH to it.
This analysis needs to be invalidated before the function is deleted.
This is a symptom of a more general problem that I describe in more detail
below (and describe 3 possible solutions).
$ cat foo.ll
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
declare i32 @bar()
define internal i32 @foo() {
entry:
%call4 = call i32 @bar()
%cmp5 = icmp eq i32 %call4, 0
br i1 %cmp5, label %if.then6, label %if.end8
if.then6:
ret i32 0
if.end8:
ret i32 1
}
$ ~/pg/d+a/bin/opt foo.ll -passes='module(function(jump-threading),globaldce)'
-debug-pass-manager -disable-output
Starting llvm::Module pass manager run.
Running pass: VerifierPass on foo.ll
Running analysis: VerifierAnalysis
Running pass: PassManager<llvm::Module> on foo.ll
Starting llvm::Module pass manager run.
Running pass: ModuleToFunctionPassAdaptor<llvm::PassManager<llvm::Function> >
on foo.ll
Running analysis:
InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Function>, llvm::Module>
Starting llvm::Function pass manager run.
Running pass: JumpThreadingPass on foo
Running analysis: TargetLibraryAnalysis
Running analysis: LazyValueAnalysis
Running analysis: AssumptionAnalysis
Finished llvm::Function pass manager run.
Running pass: GlobalDCEPass on foo.ll
While deleting: label %entry
An asserting value handle still pointed to this value!
UNREACHABLE executed at /home/sean/pg/llvm/lib/IR/Value.cpp:800!
(bugzilla sometimes mangles things so here is a copy preserving the formatting:
<a href="http://reviews.llvm.org/P6117">http://reviews.llvm.org/P6117</a>)
This same sort of issue will apply generically to any
<outer>To<inner>PassAdaptor. In fact, I ran into this initially when building
test-suite with <a href="http://reviews.llvm.org/D21921">http://reviews.llvm.org/D21921</a> applied (and using a fairly
decent pipeline that contained
`module(...,cgscc(...,inline,...function(...,jump-threading,...)),...)` that
happened to run into a similar issue)
I see 3 solutions:
1. Have the ModuleToFunctionPassAdaptor invalidate all function analyses right
after it finishes. This is safe and simple solution (that's the nature of a
cache after all).
2. Use a CallbackVH to invalidate the analyses. This already is done by e.g.
AssumptionCacheTracker::FunctionCallbackVH. This would mean that the
AnalysisManager will need to hold CallbackVH's for invalidating corresponding
analyses. For SCC's and Loop's we would need to add a similar destruction
notification mechanism since they aren't Value's and so CallbackVH can't be
used with them.
3. Require passes to manually invalidate analyses before deleting functions.
This might entail a large maintenance and test burden and is generally
error-prone. But if the number of passes that actually need special handling is
fairly small, then it might be a preferable solution.
I'm in favor of 1. as a simple short-term solution. If that proves problematic
(e.g. we measure significant performance to be gained by avoiding the analysis
invalidation) then it would depend on how many places would need to be updated
for 3. If only a relatively small and bounded set of passes would need special
handling, then manual invalidation is probably best. Otherwise, option 2. would
have less maintenance burden and less special code that needs to be added to
passes.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>