[llvm-commits] [llvm] r131581 - in /llvm/trunk: include/llvm/DefaultPasses.h include/llvm/Support/StandardPasses.h lib/Support/StandardPasses.cpp
Nick Lewycky
nicholas at mxc.ca
Sun May 22 02:08:18 PDT 2011
On 05/22/2011 01:40 AM, David Chisnall wrote:
> On 22 May 2011, at 00:13, Chris Lattner wrote:
>
>>> 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.
>
> LLVM plugins do not plug in to front ends, they plug in to LLVM. A pass defined in a plugin has no awareness of any specific front ends - it just transforms IR. Currently we have to load them explicitly, but the next thing on my LLVM TODO list is providing a mechanism for LLVM to automatically load plugins. The goal is to be able to just install a new plugin via your normal package manager and have installed LLVM-based compilers automatically take advantage of it.
The frontend is still responsible for loading the plugin. Is there any
reason we can't define an API for plugins that we look for and have the
frontend pass the plugin PMBuilder object to manipulate? It means that
supporting plugins that modify code generation becomes opt-in for the
llvm-using program, but it we do that once per frontend and don't need
to worry about dealing with every possible frontend-plugin combination.
Making it opt-in would be much preferred, actually.
> The entire point of my changes was to avoid the NxM problem where you need special code for every optimisation / consumer combination.
>
>>> 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'm not really sure that I see the problem with that. If static initialisers are really an issue, then we can always move to a more lazy initialisation mechanism, but we still need some mechanism for plugins, when loaded, to add their passes to the standard list.
Static initializers are forbidden due to interactions with threads.
Imagine that two libraries independently use LLVM to provide their
underlying behaviour, and a single program links against both those
libraries. We don't want the two LLVMs to interact with each other,
which is why we have LLVMContext. Statics aren't inside an LLVMContext,
breaking this model.
>> I added the extension point mechanism, please review it and propose some specific new extension points that will do what you need. Thanks David, StandardPasses.h has long needed a good cleanup.
>
> I've had a quick look, and I'm still not seeing how it addresses the problem. How does it allow an LLVM plugin to modify the set of default passes that are returned to optimisation consumers?
>
> Your code looks reasonably clean, but doesn't seem to address the problem. We now have a list of extension functions, but no way for plugins to modify that list.
Indeed, but you can add that around this API.
Nick
More information about the llvm-commits
mailing list