[llvm-bugs] [Bug 28400] New: [PM] Analysis invalidation when deleting IRUnitT's (in particular functions)

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28400

            Bug ID: 28400
           Summary: [PM] Analysis invalidation when deleting IRUnitT's (in
                    particular functions)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: chisophugis at gmail.com
                CC: llvm-bugs at lists.llvm.org
            Blocks: 28315
    Classification: Unclassified

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:
http://reviews.llvm.org/P6117)


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 http://reviews.llvm.org/D21921 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160702/dcf67d1e/attachment-0001.html>