[llvm-commits] [llvm] r131581 - in /llvm/trunk: include/llvm/DefaultPasses.h include/llvm/Support/StandardPasses.h lib/Support/StandardPasses.cpp

[Chris Lattner]

On May 21, 2011, at 3:36 PM, David Chisnall wrote:
> On 21 May 2011, at 21:53, Chris Lattner wrote:
> 
>> Lets keep your patch in until we have a chance to resolve this.  I assume that you're doing your work in the context of dragonegg?  If so, can you switch dragonegg over to the new PassManagerBuilder?
> 
> I'm not using dragon egg at all, although some of the passes that I've written can be used with it if you are compiling Objective-C code.

Oh, ok.  I thought dragonegg was the only one that had plugins, but now that I actually engage the brain, dragonegg is the plugin in the situation!

> My point was that there should be no tight coupling between the front ends and the optimisations at all, because then you need one plugin for every front end that might use the passes, which adds silly amounts of complexity.  

I don't understand what you mean here.  Plugins are inherently tied to the frontend they are plugging into, and I don't see how that is related to tight coupling between frontends and optimizations.

> The aim is to have an interface for plugins provided by LLVM and an interface for front ends / things that drive optimisations provided by LLVM, with the former controlling the semantics of the latter.

Doing this though global variables is a non-starter to me.  It violates the entire spirit of llvm as a library.  It seems perfectly reasonable to define a plugin API that doesn't require tight frontend knowledge *or* global variables, but it would require some implementation effort.  Just dropping in a bunch of global variables isn't the way to go.

> I also aimed to keep the existing front end API, because making every front end author rewrite how they drive the optimisation system is just going to irritate people.

To bad, we do the right thing and expect clients of the API to adapt.  There is nothing special w.r.t. this part of the API.

>> Where addMyLatePerFunctionExtensions is declared as something like this:
>> 
>> void addMyLatePerFunctionExtensions(const PMBuilder &Builder, PassManagerBase &PM) {
>> if (Builder.getOptLevel() > 2 && Builder.getOptSizeLevel() == 0)
>>   PM.add(createMyPass());
>> }
>> 
>> Would something like this work for you?  What are the places that you'd like to add passes, specifically?
> 
> Yes, I think that works for me.  The interface is clean, and it gives plugins fine-grained control over which optimisations are added.  I think it would also be interesting if the PMBuilder had could store some extra information, such as the language (or languages) used in the front end, although I'm not sure how that would work with LTO (maybe via some module-level metadata?).  I can imagine some optimisations that would only make sense for C++, for example, so a Python front end wouldn't want to run them but both clang and DragonEgg would when compiling C++ (but not necessarily when compiling C).

Instead of making the plugin "know" about the language, it is better for it to do a cheap check up front, and early exit.  Many other passes have similar behavior.

> I think there are thee places where I might want to add passes:
> 
> - Right at the start, when the code is as close to the source language as possible.
> - When the basic analysis and simplification stuff has run.
> - Near the end

Please pick specific places, since your concrete application is the driver for this, it doesn't help if it doesn't solve your problem :)

-Chris