[llvm-dev] [RFC] Generalize out-of-tree pass support
Michael Kruse via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 24 20:59:15 PDT 2019
Am So., 22. Sept. 2019 um 07:12 Uhr schrieb Andrzej Warzynski via
llvm-dev <llvm-dev at lists.llvm.org>:
> I have a few questions/remarks:
> 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.
There's dual use: without LLVM_<PLUGIN>_LINK_INTO_TOOLS, the plugin
can be imported using the -load mechanism.
> 2. Does your patch make `PLUGIN_TOOL` obsolete (e.g.
> https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Hello/CMakeLists.txt#L18)?
> AFAIK `PLUGIN_TOOL` is only needed to enable dynamically loaded plugins
> on Windows, but from what I can tell you achieved that without using it?
> (sadly I've not been able to test your patch on Windows)
PLUGIN_TOOL must be used to allow plugins such as "Hello" to link
against symbols of an executable. On Windows, import symbols need to
know which library it is imported from. "Hello" defines the executable
opt as source of its symbols, consequently it cannot be imported in
other executables such as bugpoint, llvm-reduce or clang. In addition
to use it, one must also set cmake -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS
to make the executable export those symbols. However, Windows dlls
have a limit of 2^16 imported symbols and LLVM exceeds that by far.
Therefore there is a util script extract_symbols.py to limit the
exports to those that are most probably used. However, I could not
(yet) make this work with Polly, there are always symbols missing.
But it doesn't even work on Linux since the linker only adds symbols
(from static libraries) that are required within the executable. So if
a plugin needs one that is not added to the executable, the plugin is
in bad luck. IMHO the concept of dynamically linking to symbols in
executables is pretty broken. LTO will worsen the problem since it
will inline public symbols and remove the ones unused inside the
executable.
tl;dr: They are different: D61446 for statically linking a plugin,
PLUGIN_TOOL is for dynamically linking a plugin.
Michael
More information about the llvm-dev
mailing list