[LLVMdev] Pass vs. FunctionPass
Chris Lattner
sabre at nondot.org
Thu Jun 24 13:13:18 PDT 2004
On Thu, 24 Jun 2004, Vladimir Prus wrote:
> I wonder in what cases FunctionPass is better that Pass. For example,
> addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes
> FunctionPassManager.
Here's a simple way to look at it. Use a Function pass whenever you can.
A function pass will always work where a Pass works (it derives from pass
as you've noticed), but not the other way around.
In particular, there are *strict* rules that must be followed by
FunctionPass's, described in the HowToWriteAPass document. Like Patrick
mentioned, these allow the pass manager to optimize the execution of
passes on a module, and eventually will allow us to compile functions in
parallel on different threads at the same time.
> Another question is about FunctionPassManager::run(Function&) and
> FunctionPass(Function&). The former calls the later, which is fine, but the
> latter looks like this:
>
> bool FunctionPass::run(Function &F) {
> if (F.isExternal()) return false;// Passes are not run on external
> functions!
>
> return doInitialization(*F.getParent()) | runOnFunction(F)
> | doFinalization(*F.getParent());
> }
>
> So, with FunctionPassManager, doInitializaton will be called once for
> each function, which is strange, given that that method takes Module&.
> When this behaviour is desirable?
That *is* odd, I've never noticed that code before. I think that the
FunctionPassManager is only used by the JIT. For normal optimization and
static compiles, you will get a doInitialization once at the beginning of
the module, a whole bunch of runOnFunctions, and a doFinalization call at
the end (as you would expect).
I'm not sure what the right semantics are in the JIT using the
functionpassmanager. In any case your code should work correctly (because
it is a function pass) it's a performance thing. What do you need to do
in your doInit/finalize calls for codegeneration?
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/
More information about the llvm-dev
mailing list