[LLVMdev] please advise on PassManager
clattner at apple.com
Wed Oct 17 15:46:10 PDT 2012
On Oct 17, 2012, at 1:46 PM, Chandler Carruth <chandlerc at google.com> wrote:
> I'm not sure what the difference here is between -O0 and -O1, but this *is* intended behavior. This "interlacing" of passes is really important for C++ optimization (among other things) where optimizing a function can dramatically shrink it (due to abstraction penalties being removed)… which then makes it a much strongly inline candidate.
> Yes, this is the intended behavior of the CGSCC pass, and in an optimized build there is a pass manager extension hook for putting a function pass into this process.
> However, the -O1 (and higher) pass managers expose the OptimizeLast extension point after several module passes, and thus they run in their own function pass manager. This is desirable for at least some of the users of that extension point. But in -O0, the *only other pass* is the inliner, and it's not really the normal inliner, it is just the always-inliner. There is no extension point offered which would not fall into this inliner's CGSCC pass manager, because we cannot even express such an extension point today.
> I've almost finished an interim fix to this which will take the following form:
> 1) Introduce a new 'BarrierNoop' module pass which has no effect other than to go into the optimization pipeline, and terminate any of the implicitly nested pass managers in place. This will even be useful on the 'opt' commandline, for example to build two independent CGSCC pass managers.
> 2) Teach the -O0 extension point that ASan and other "late instrumentation" passes use to have a barrier in the pipeline before it.
> potential 3) I could also add more extension points that provide finer grained control over this and/or clarify the naming of the extension points to document the guarantees they provide in terms of composing with other pass managers.
> Sound reasonable?
Yes. This sounds like a quite reasonable hack to me, please document it as such very clearly though :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev