[LLVMdev] Optimization pass questions

Larry Gritz lg at larrygritz.com
Wed Aug 11 16:55:09 PDT 2010


I have a whole slew of questions about optimization passes.  Answers to any or all would be extremely helpful:

How important are doInitialization/doFinalization?  I can't detect any difference if I use them or not.  Why does the function pass manager have doInitialization/doFinalization, but the global pass manager doesn't?  If I am applying the function passes to many functions, do I doInitialization/run/doFinalization for each function I apply the passes to, or do I initialize/finalize just once?

Where is it documented which passes should be part of the global versus which should be function passes?  Some *appear* to work with either, some have errors if you use it wrong.  I haven't found a way to tell without trying, and no indications that I'm not using it wrong but in a way that's too subtle to crash or catch it.

Is the best protocol to do function passes first, then global?  After that, should you do function passes again for good measure, or is that redundant?  Does inlining go best in function or global?  Does the strategy change if I really only need to directly call a few functions in the module, the others existing only in case they are needed by the dynamically-generated code that I'm JITing?

It seems that the combinatorics of which passes to apply, and in which order (including doing some multiple times), are pretty daunting.  Other than the Kaleidescope tutorial (too simple) and the StandardPasses.h (too complex?) I can't find any other examples, much less pro/con discussion or guidance.  Does anybody have any pointers to web pages or other docs where people have shared their experiences walking through the space of possible pass combinations? 

The application of all of this for me is to JIT dynamically-generated code, so in contrast to a fully offline compiler, I'm fairly sensitive to achieving a good balance of optimization of the JITed code versus time spent doing the optimizations.  In case that changes any of your answers.

Thanks, any info would be very appreciated!

--
Larry Gritz
lg at larrygritz.com






More information about the llvm-dev mailing list