[llvm-commits] inliner holds onto ValueMap

Nick Lewycky nicholas at mxc.ca
Wed May 12 00:23:36 PDT 2010


I've encountered a problem while working on MergeFunctions, a 
ModulePass. The Inliner caches its results in a ValueMap<Function*, 
InlineCost>, and that value map is a member of the InlineCostAnalyzer 
which is a member of SimpleInliner, aka. the -inline pass. When my pass 
tries to RAUW a function it triggers an abort in the ValueMap, because 
RAUW'ing a value map key is illegal.

Here's the pass manager structure:

Pass Arguments:  -basiccg -inline -mergefunc -preverify -domtree -verify
Target Data Layout
   ModulePass Manager
     Basic CallGraph Construction
     Call Graph SCC Pass Manager
       Function Integration/Inlining
     Merge Functions
     FunctionPass Manager
       Preliminary module verification
       Dominator Tree Construction
       Module Verifier

so I tried the obvious fix, which is to add a clear() method to 
InlineCostAnalyzer that clears the cache, patch attached. It fixes my 
testcase! That's not why I'm emailing.

My change breaks test/Transforms/Inline/externally_available.ll which 
contains:

   define available_externally i32 @test_function() {
     ret i32 4
   }

   define i32 @result() {
     %A = call i32 @test_function()
     %B = add i32 %A, 1
     ret i32 %B
   }

and expects that after opt -inline -constprop, @test_function will have 
been deleted from the IR.

Is my approach for Inliner cleanup correct? Is there a guarantee that 
doFinalization() on an CallGraphSCCPass will be called before the next 
ModulePass starts? What about when the CGSCC iterates, will it wipe the 
cache in between (we don't want it to). Secondly, why does my patch 
modify the behaviour of this test? Why should inlining delete that 
function at all?

Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inliner-free-valuemap.patch
Type: text/x-patch
Size: 1631 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100512/8e0dd331/attachment.bin>


More information about the llvm-commits mailing list