<div dir="ltr">> 1. As far as I can tell, this mechanism relies on the plugin being located somewhere within LLVM the tree so that everything happens within one CMake run. Otherwise the pass registration won't work - at least in the case of static linking. IMHO this is fine - AFAIK it's not something that could easily be worked around.<div><br></div><div>One can use `LLVM_ENABLE_PROJECTS` and `LLVM_EXTERNAL_${project}_SOURCE_DIR`, so this is fully parametric.</div><div><br></div><div>> 2. Does your patch make `PLUGIN_TOOL` obsolete</div><div><br></div><div>I'll double -check and update the patch accordingly if needs be. At first glance I'd say I'm generalizing PLUGIN_TOOL, but missed the error message for unsupported platform.</div><div><br></div><div>> 3. At the coming LLVM Dev Meeting I'll be presenting a tutorial on writing LLVM passes for beginners and I'd like to advertise this patch</div><div><br></div><div>Good :-)</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 22, 2019 at 2:12 PM Andrzej Warzynski <<a href="mailto:Andrzej.Warzynski@arm.com">Andrzej.Warzynski@arm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Serge,<br>
<br>
Thank you for doing this - that's a lot of great work that makes LLVM <br>
plugin registration very straightforward to use. The implementation and <br>
the interface make a lot of sense! I've noticed other people on the <br>
mailing list asking for similar functionality, so there's definitely <br>
need for this sort of infrastructure. I do hope that it lands in LLVM <br>
sooner rather than later.<br>
<br>
I have a few questions/remarks:<br>
1. As far as I can tell, this mechanism relies on the plugin being <br>
located somewhere within LLVM the tree so that everything happens within <br>
one CMake run. Otherwise the pass registration won't work - at least in <br>
the case of static linking. IMHO this is fine - AFAIK it's not something <br>
that could easily be worked around.<br>
<br>
2. Does your patch make `PLUGIN_TOOL` obsolete (e.g. <br>
<a href="https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Hello/CMakeLists.txt#L18" rel="noreferrer" target="_blank">https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Hello/CMakeLists.txt#L18</a>)? <br>
AFAIK `PLUGIN_TOOL` is only needed to enable dynamically loaded plugins <br>
on Windows, but from what I can tell you achieved that without using it? <br>
(sadly I've not been able to test your patch on Windows)<br>
<br>
3. At the coming LLVM Dev Meeting I'll be presenting a tutorial on <br>
writing LLVM passes for beginners and I'd like to advertise this patch. <br>
Is that OK with you? I think that this is really worthwhile sharing with <br>
the wider community.<br>
<br>
Thanks again for working on this,<br>
-Andrzej<br>
<br>
<br>
On 20/09/2019 14:56, Serge Guelton via llvm-dev wrote:<br>
> Hi folks,<br>
> <br>
> I've been working for a few months on a proposal to make it easier to develop<br>
> out-of-tree passes, and have them linked either statically or dynamically,<br>
> within LLVM. This includes automatic integration within clang, opt and bugpoint.<br>
> <br>
> The goal is to lower the bar for people who develop out-of tree passes: they can<br>
> maintain their code base in a third-party repo, pick it at config time and build<br>
> it statically or dynamically.<br>
> <br>
> As a side-effect, this provides a generalization of the polly-specific code<br>
> that spread at several locations of the code base (and removes most of the<br>
> explicit mention of Polly itself, without removing the functionality, obviously).<br>
> <br>
> Both legacy and new pass managers are supported.<br>
> <br>
> From the review's documentation:<br>
> <br>
> <br>
> LLVM provides a mechanism to automatically register pass plugins within<br>
> ``clang``, ``opt`` and ``bugpoint``. One first needs to create an independent<br>
> project and add it to either ``tools/`` or, using the MonoRepo layout, at the<br>
> root of the repo alongside other projects. This project must contain the<br>
> following minimal ``CMakeLists.txt``:<br>
> <br>
> .. code-block:: cmake<br>
> <br>
> add_llvm_pass_plugin(Name source0.cpp)<br>
> <br>
> The pass must provide two entry points for the new pass manager, one for static<br>
> registration and one for dynamically loaded plugins:<br>
> <br>
> - ``llvm::PassPluginLibraryInfo get##Name##PluginInfo();``<br>
> - ``extern "C" ::llvm::PassPluginLibraryInfo llvmGetPassPluginInfo() LLVM_ATTRIBUTE_WEAK;``<br>
> <br>
> <br>
> Pass plugins are compiled and link dynamically by default, but it's<br>
> possible to set the following variables to change this behavior:<br>
> <br>
> - ``LLVM_${NAME}_LINK_INTO_TOOLS``, when sets to ``ON``, turns the project into<br>
> a statically linked extension<br>
> <br>
> The review also contains an example of pass plugin, `llvm/examples/Bye/Bye.cpp`.<br>
> <br>
> The associated review is available at <a href="https://reviews.llvm.org/D61446" rel="noreferrer" target="_blank">https://reviews.llvm.org/D61446</a>, Michael<br>
> Kruse has already done a lot of review, I think it's time to gather more<br>
> feedback, so if you're interested... jump in!<br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
</blockquote></div>