[Plugins] Add a slim plugin API to work together with the new PM
Needs ReviewPublic

Authored by philip.pfaffe on Jul 11 2017, 8:06 AM.



Add a new plugin API. This closes the gap between pass registration and out-of-tree passes for the new PassManager.

Unlike with the existing API, interaction with a plugin is always initiated from the tools perspective. I.e., when a plugin is loaded by the PluginLoader, it resolves and calls a well-known symbol llvmPluginGetInfo to obtain details about the plugin. The fundamental motivation is to get rid of as many global constructors as possible.
The API exposed by the plugin info is kept intentionally minimal.

Diff Detail

philip.pfaffe created this revision.Jul 11 2017, 8:06 AM

Retain backwards compatibility with plugins for the legacy PM.

lksbhm added a subscriber: lksbhm.Jul 12 2017, 4:49 AM

Very cool to see this working!

Correctly value-initialize the PluginInfo.

chandlerc added inline comments.Wed, Feb 28, 3:43 AM
33 ↗(On Diff #108063)

This seems like a somewhat nasty layering...

If plugins fundamentally deal in pass builders, I wouldn't expect the plugin infrastructure to be in the Support library at all. I think the only reason the plugin stuff started off in the support library is because it relied exclusively on global ctors to connect to any functionality. I really like the idea of moving away from that for plugins and having a more proper callback mechanism, but I think it means we need to either use some abstraction or just make the plugin logic (somewhat) specific to *pass builder* plugins.

Beyond getting the layering and pass build stuff designed nicely, I suspect we should rope some folks more broadly in the community in to make sure the high level approach to plugins here makes sense long term... I'll try to ask around and see who has opinions here.

Improve Layering: Move New-PM Pass Plugins into the Passes library

[NFC] clang-format

chandlerc added inline comments.Mon, Mar 12, 7:51 PM

We should have some documentation around when/where this should be incremented...


We should probably stick this into Compiler.h


Probably some documentation here would be good. ;]

Also, should this be weak so that it is OK if we never load a library that defines it?


Out of curiosity -- why use a macro rather than just documenting that a plugin must define the above function?


This whole class needs doxygen comments. =D

Also, should it be called PassPlugin? And maybe be in the same header as above?


I think this is indicative that optional isn't the right return type here... I think you want something more like llvm::Expected here so you can put the error message into return and make this more library friendly.


maybe load-pass-plugin?

philip.pfaffe added inline comments.Tue, Mar 13, 11:32 AM

Mostly so that clients don't forget the extern "C". I just thought it was convenient and liked the declarative style.

If you have strong feelings about this I can document it instead, I'm not really married to the idea.


I put the two classes in different headers because they have different clients. The PassPlugin.h header contains what's required on the client side, i.e. in the actual pass plugin. The Plugin class here is on the other hand only used by the driver to represent loaded plugins.

philip.pfaffe marked 5 inline comments as done.

Address review comments, mostly adding commentary and renaming things.