Commit Graph

15 Commits

Author SHA1 Message Date
Nico Weber 5533357c38 Fix build warning compiling TestPlugin on Windows and disable Passes plugin stuff on Windows since it fundamentally can't work
Aaron Ballman reported that TestPlugin warned about it using exception handling
without /EHsc flag, and that llvmGetPassInfo() had conflicting export
attributes (dllimport in the header, dllexport in the source file).

/EHsc is because TestPlugin didn't use the llvm_ cmake functions, so
llvm_update_compile_flags didn't get called for the target
(llvm_update_compile_flags explicitly passes /Ehs-c-, which fixes the warning).
Use add_llvm_loadable_module instead of add_library(... MODULE) to fix this.
This also has the side effect of not building the plugin on Windows. That's not
a big problem, since before the plugin was built on Windows, but the test
didn't attempt to load it, due to -DLLVM_ENABLE_PLUGIN not being passed to
PluginsTests.cpp during compilation on Windows. This makes the plugin behavior
consistent with e.g. lib/Transforms/Hello/CMakeLists.txt. (This also
automatically sets LTDL_SHLIB_EXT correctly.)

The dllimport/dllexport warning is more serious: Since LLVM doesn't generally
use export annotations for its code, the only way the plugin could link was by
linking in some LLVM libraries both into the test and the dll, so the plugin
would call the llvm code in the dll instead of the copy in the main executable.
This means globals weren't shared, and things generally can't work. (I think
there's a build config where you can build a LLVM.dll which might work, but
that wasn't how the test was configured. If that config is used, the dll should
still be built, but I haven't checked).

Now that add_llvm_loadable_module is used, LLVM_LINK_COMPONENTS got linked into
both executable and plugin on posix too, so unset it after the executable so
that the plugin doesn't end up with a 2nd copy of things on posix.

https://reviews.llvm.org/D47082

llvm-svn: 332796
2018-05-19 03:05:30 +00:00
Nico Weber 718a42cfce use standard llvm cmake formatting for targets defined in plugin tests
llvm-svn: 332709
2018-05-18 12:42:30 +00:00
Nico Weber 1238981938 Give shared modules in unittests the platform-native extension, make PipSqueak a MODULE
As far as I can tell from revision history, there's no good reason to call
these files .so instead of .dll in Windows, so use the normal extension.

Also change PipSquak from SHARED to MODULE -- it's never passed to
target_link_libraries() and only loaded via dlopen(), so MODULE is more
appropriate. This makes it possible to delete a workaround for SHARED ldflags
being not quite right as well.

No intended behavior change.
https://reviews.llvm.org/D46898

llvm-svn: 332487
2018-05-16 16:29:05 +00:00
Nico Weber 8a95329923 Rename three cxx files in unittests to cpp.
LLVM uses cpp as its C++ file extension, these are the only three cxx file in
the monorepo. These files apparently were called to escape a CMake check -- use
the LLVM_OPTIONAL_SOURCES mechanism that's meant as an escape for this case
instead.

No intended behavior change.
https://reviews.llvm.org/D46843

llvm-svn: 332368
2018-05-15 16:30:30 +00:00
Aaron Ballman 1368e484e3 Move the TestPlugin project into the Tests folder in CMake.
llvm-svn: 331387
2018-05-02 18:57:14 +00:00
Reid Kleckner e765d633c4 Fix PluginsTests failure on Windows buildbots by enabling it everywhere
lit is picking up a stale executable in the unittests tree, which is
failing on Windows.

To simplify the CMake and avoid problems like this in the future, now we
always compile the test, but the test exits successfully when plugins
are not enabled.

llvm-svn: 330867
2018-04-25 20:16:24 +00:00
Gabor Buella f4bd34b026 Avoid a warning on pointer casting, NFC
Reviewers: philip.pfaffe	

Reviewed By: philip.pfaffe	

Differential Revision: https://reviews.llvm.org/D46012

llvm-svn: 330817
2018-04-25 12:15:34 +00:00
Mikhail Maltsev aeb6c48d29 [Unittests] Fix plugins test
Summary:
Currently the PluginsTests.LoadPlugin unit test is failing in
LLVM configurations that have LLVM_EXPORT_SYMBOLS_FOR_PLUGINS enabled
because the EnableABIBreakingChecks symbol is missing.

This patch fixes the issue by linking some additional libraries to the
test plugin if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is enabled.

Reviewers: philip.pfaffe

Reviewed By: philip.pfaffe

Subscribers: mgorny, llvm-commits, rogfer01

Differential Revision: https://reviews.llvm.org/D45811

llvm-svn: 330329
2018-04-19 14:02:46 +00:00
Philip Pfaffe 6b65523671 Revert "Followup for r329293: Temporarily disable the breaking test on windows."
This reverts commit r329393 / b52ba35e7759cd4002221be1dbb63ec80fde21ec.

llvm-svn: 329514
2018-04-07 20:22:38 +00:00
Philip Pfaffe ec79c00f20 Followup for r329293: Temporarily disable the breaking test on windows.
This test is failing on windows bots. Disable it temporarily to unbreak
the windows bots.

llvm-svn: 329393
2018-04-06 13:39:16 +00:00
Philip Pfaffe 802ee317e6 Another fix for r329293: Unbreak the windows bots
Only build the unittest if plugins are enabled. Link components into the
TestPlugin on windows and cygwin.

llvm-svn: 329318
2018-04-05 17:20:45 +00:00
Philip Pfaffe 7b7637b9eb Fix r329293: Add a missing CMake dependency
The unittest plugin indirectly includes Attributes.gen, so make sure its
target depends on the appropriate tablegen target.

llvm-svn: 329308
2018-04-05 15:58:27 +00:00
Philip Pfaffe 131fb978b0 Re-land r329273: [Plugins] Add a slim plugin API to work together with the new PM
Fix unittest: Do not link LLVM into the test plugin.
Additionally, remove an unrelated change that slipped in in r329273.

llvm-svn: 329293
2018-04-05 15:04:13 +00:00
Philip Pfaffe e6b49ef286 Revert "[Plugins] Add a slim plugin API to work together with the new PM"
This reverts commit ecf3ba1ab45edb1b0fadce716a7facf50dca4fbb/r329273.

llvm-svn: 329276
2018-04-05 12:42:12 +00:00
Philip Pfaffe e8f3ae9da0 [Plugins] Add a slim plugin API to work together with the new PM
Summary:
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, it
resolves and calls a well-known symbol `llvmGetPassPluginInfo` 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.

Reviewers: chandlerc

Reviewed By: chandlerc

Subscribers: bollu, grosser, lksbhm, mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D35258

llvm-svn: 329273
2018-04-05 11:29:37 +00:00