[LLVMdev] problem with inlining pass

Duncan Sands baldrick at free.fr
Thu Mar 1 00:29:10 PST 2012


Hi Jochen,

> My llvm version is 3.0 release.
> I have a module generated by clang. When I optimize it, I first add an
> inlining pass (llvm::createFunctionInliningPass), then these passes:
> - own FunctionPass
> - llvm::createPromoteMemoryToRegisterPass
> - llvm::createInstructionCombiningPass
> - llvm::createDeadInstEliminationPass
> - llvm::createDeadStoreEliminationPass
> - new llvm::DominatorTree()
> - new llvm::LoopInfo()
> - llvm::createLoopSimplifyPass()
> - own FunctionPass
>
> The problem is that the last function pass (and maybe the others too)
> gets called
> with functions that the inlining pass is supposed to delete.

I think this is a normal consequence of how the pass manager schedules
passes.  Suppose you have the following call graph: A --> B, i.e. function
A calls function B.  Passes will be scheduled as follows:

First, the inliner will be run on function B.  This won't do anything
since B doesn't call anything.  Then each function pass will be run on
B in turn.  That means that your function pass will be run on B.  Then
the inliner will be run on function A.  This may inline function B into
function A then delete B.  Then each function pass will be run on A.
In short the inliner works its way up the callgraph, and after it runs
on each function, all other function passes are run on that function.
That's why I think it is normal for your pass to be run on function B
even if the inliner is going to delete B after inlining it into A.

Ciao, Duncan.



More information about the llvm-dev mailing list