Before this patch, the cmake disabled loadable modules when compiling
with Visual Studio. However, the reason for this is a limitation of the
Windows DLLs, thus this restriction should apply to any compiler for the
Windows platform, such as MinGW, Cygwin, icc, etc.
Differential Revision: https://reviews.llvm.org/D87524
A build on `sparcv9-sun-solaris2.11` with `-DLLVM_ENABLE_PIC=Off` failed
linking `LLVMPolly.so`:
[2277/2297] Linking CXX shared module lib/LLVMPolly.so
FAILED: lib/LLVMPolly.so
[...]
ld: fatal: relocation error: R_SPARC_H44: file tools/polly/lib/CMakeFiles/obj.Polly.dir/Analysis/DependenceInfo.cpp.o: symbol .data._ZL16__gthread_active (section): invalid shared object relocation type: ABS44 code model unsupported
[...]
As on many other targets, one cannot link non-PIC objects into a shared
object on Solaris/sparcv9.
The following patch avoids this by not building the library without PIC.
It allowed the build to finish.
Differential Revision: https://reviews.llvm.org/D85627
Configure CMake to setup source-groups for Polly. Source groups
describe how source files should be organized in IDEs. By default, all
headers are dumped into one folder under PollyCore and all source files
into another. On disk, these files are organized into folders, but this
isn't reflected in the IDE. This change uses CMake source groups to have
the IDE reflect the on disk layout. This will make it easier to visualize
the project structure for users of Visual Studio and XCode
Patch by Christopher Tetreault <ctetreau@quicinc.com>
Reviewed By: Meinersbur, grosser
Differential Revision: https://reviews.llvm.org/D72117
CMake generates the exports file wrongly if the CMAKE_BUILD_TYPE is
unset for multi-configuration generators.
The generated file lib/cmake/polly/PollyExports-all.cmake then contains:
set_target_properties(LLVMPolly PROPERTIES
IMPORTED_LOCATION_ my_build_dir/lib/LLVMPolly.so)
set_target_properties(Polly PROPERTIES
IMPORTED_LOCATION_ my_build_dir/lib/libPolly.a)
This patch conditionalizes the underscore.
Patch by: Marcin Copik
Differential Revision: D53376
llvm-svn: 346231
CMake insists that for each target, one uses only the non-keyword
version of target_link_library
target_link_library(mytarget lib)
or the one with PUBLIC/PRIVATE/INTERFACE keyword:
target_link_library(mytarget PUBLIC lib)
Otherwise, CMake fails with the error message:
The keyword signature for target_link_libraries has already been used with
the target "mytarget". All uses of target_link_libraries with a target
must be either all-keyword or all-plain.
Change all occurances of target_link_library to the newer keyworded
version to avoid such errors. Some already have been changed in r319840,
but might not be sufficient for all build configurations to build
the doxygen manual.
Reported-by: Tanya Lattner <tanyalattner@llvm.org>
llvm-svn: 322376
find_library(lib) stores the result in the variable "lib", which is also
cached in CMakeCache.txt. This could theoretically conflict if jsoncpp
required two libraries, which each would get cached as "lib". Use a
more descriptive and disambiguative "jsoncpp_${libname}" for that.
llvm-svn: 308289
Use ${libname} instead of ${lib}. By a coincidence, this worked
because ${lib} also the variable used for finding the libjsoncpp.so
full path.
llvm-svn: 308288
pkg_search_module(JSONCPP) should set
JSONCPP_LIBDIR/JSONCPP_LIBRARY_DIRS to where the libjsoncpp.so can be
found. However, on Ubuntu 14.04 LTS (Trusty Tahr) it returns /usr/lib
while the libjsoncpp library can be found at
/usr/lib/x86_64-linux-gnu/libjsoncpp.so. Thus, while searching for
the full path of the jsoncpp library, it is not found.
JSONCPP_LIBDIR is correctly set to /usr/lib/x86_64-linux-gnu on e.g.,
Ubuntu 16.04 LTS (Xenial Xerus )
Fix by removing the NO_DEFAULT_PATH flag, in order to search the system
default paths even if the library is not found in
JSONCPP_LIBDIR/JSONCPP_LIBRARY_DIRS.
This fixes bug llvm.org/PR33798.
llvm-svn: 308287
Summary:
As of now, Polly uses llvm-config to set up LLVM dependencies in an out-of-tree build.
This is problematic for two reasons:
1) Right now, in-tree and out-of-tree builds in fact do different things. E.g., in an in-tree build, libPolly depends on a handful of LLVM libraries, while in an out-of-tree build it depends on all of them. This means that we often need to treat both paths seperately.
2) I'm specifically unhappy with the way libPolly is linked right now, because it just blindly links against all the LLVM libs. That doesn't make a lot of sense. For instance, one of these libs is LLVMTableGen, which contains a command line definition of a -o option. This means that I can not link an out-of-tree libPolly into a tool which might want to offer a -o option as well.
This patch (mostly) drop the use of llvm-config in favor of LLVMs exported cmake package. However, building Polly with unittests requires access to the gtest sources (in the LLVM source tree). If we're building against an LLVM installation, this source tree is unavailable and must specified. I'm using llvm-config to provide a default in this case.
Reviewers: Meinersbur, grosser
Reviewed By: grosser
Subscribers: tstellar, bollu, chapuni, mgorny, pollydev, llvm-commits
Differential Revision: https://reviews.llvm.org/D33299
llvm-svn: 307650
Allow using a system's install jsoncpp library instead of the bundled
one with the setting POLLY_BUNDLED_JSONCPP=OFF.
This fixes llvm.org/PR32929
Differential Revision: https://reviews.llvm.org/D32922
llvm-svn: 302336
Generate a PollyConfig.cmake for use with Cmake's find_package in
out-of-tree projects.
Contributed-by: Philip Pfaffe <philip.pfaffe@gmail.com>
Differential Revision: https://reviews.llvm.org/D30495
llvm-svn: 297395
This patch adds an option to build against a version of libisl already
installed on the system. The installation is autodetected using the
pkg-config file shipped with isl.
The detection of the library is in the FindISL.cmake module that creates
an imported target.
Contributed-by: Philip Pfaffe <philip.pfaffe@gmail.com>
Differential Revision: https://reviews.llvm.org/D30043
llvm-svn: 296361
The flag -fvisibility=hidden flag was used for the integrated Integer
Set Library (and PPCG) to keep their definitions local to Polly. The
motivation was the be loaded into a DragonEgg-powered GCC, where GCC
might itself use ISL for its Graphite extension. The symbols of Polly's
ISL and GCC's ISL would clash.
The DragonEgg project is not actively developed anymore, but Polly's
unittests need to call ISL functions to set up a testing environment.
Unfortunately, the -fvisibility=hidden flag means that the ISL symbols
are not available to the gtest executable as it resides outside of
libPolly when linked dynamically. Currently, CMake links a second copy
of ISL into the unittests which leads to subtle bugs. What got observed
is that two isl_ids for isl_id_none exist, one for each library
instance. Because isl_id's are compared by address, isl_id_none could
happen to be different from isl_id_none, depending on which library
instance set the address and does the comparison.
Also remove the FORCE_STATIC flag which was introduced to keep the ISL
symbols visible inside the same libPolly shared object, even when build
with BUILD_SHARED_LIBS.
Differential Revision: https://reviews.llvm.org/D24460
llvm-svn: 281242
We cannot built ISL as shared object because we build it with
-fvisibility=hidden; The created shared object would have no accessible symbols.
The reason it is built with -fvisibility=hidden is because opt/clang might load
other libraries that have ISL embedded and whose' symbols would conflict with
Polly's private ISL. This could happend with Draggonegg.
In the future we might instead statically link PollyISL into the Polly shared
object to avoid installing the static library.
Requested-by: Vedran Miletic <vedran@miletic.net>
See-also: llvm.org/PR27306
llvm-svn: 279737
Static libraries where installed into "lib${LLVM_LIBDIR_SUFFIX}" while
shared ones into "lib". I found no justification for this behaviour.
This patch changes both types of libraries to be install into
"lib${LLVM_LIBDIR_SUFFIX}". LLVM and clang use the same behaviour.
This fixes llvm.org/PR27305.
llvm-svn: 265872
Refactor all ISL-related cmake build instructions into its own
CMakeLists.txt and build as a separate library.
This is useful to apply ISL-related build flags to ISL only and not to
Polly's files. Also, it the separation of both projects becomes clearer.
Proposed name of the library is Polly_isl. It is not "isl" to avoid
mix-up with potentially installed libisl.{a|so}.
Tested configurations:
- Windows with cmake 3.2
- Ubuntu with cmake 3.0.2
- Ubuntu with cmake 3.0.2 BUILD_SHARED_LIBS on
- Ubuntu with cmake 2.8.12.2 (LLVM minimum version)
- Ubuntu out-of-LLVM-tree
Differential Revision: http://reviews.llvm.org/D12810
llvm-svn: 248484
Put all Polly targets into a single "Polly" category (i.e.
solution folder). Previously there was no recognizable scheme and most
categories contained just one or two targets or targets didn't belong
to any category.
Reviewers: grosser
llvm-svn: 242779
Summary: Adding the flag to C++ source files emits a warning, hence we set the compile flag depending on the file's language.
Reviewers: grosser
Subscribers: Meinersbur, pollydev, llvm-commits
Projects: #polly
Differential Revision: http://reviews.llvm.org/D10809
llvm-svn: 240986
ISL with small integer optimization requires C99 to compile. gcc < 5.0
still uses C89 as default, so we need to enable the options to compile
in C99 mode.
This patch is preparing the actual activation of small integer
optimization.
Differential version: http://reviews.llvm.org/D10610
Reviewers: grosser
llvm-svn: 240322
We do not have buildbots or anything that tests this functionality, hence it
most likely bitrots. People interested to use this functionality can always
recover it from svn history.
llvm-svn: 233570
With this patch Polly is always GPL-free (no dependency on GMP any more). As a
result, building and distributing Polly will be easier. Furthermore, there is no
need to tightly coordinate isl and Polly releases anymore.
We import isl b3e0fa7a05d as well as imath 4d707e5ef2. These are the git
versions Polly currently was tested with when using utils/checkout_isl.sh. The
imported libraries are both MIT-style licensed.
We build isl and imath with -fvisibility=hidden to avoid clashes in case other
projects (such as gcc) use conflicting versions of isl. The use of imath can
temporarily reduce compile-time performance of Polly. We will work on
performance tuning in tree.
Patches to isl should be contributed first to the main isl repository and can
then later be reimported to Polly.
This patch is also a prerequisite for the upcoming isl C++ interface.
llvm-svn: 228193
This commit drops the Cloog support for Polly. The scripts and
documentation are changed to only use isl as prerequisity. In the code
all Cloog specific parts have been removed and all relevant tests have
been ported to the isl backend when it was created.
llvm-svn: 223141
This fixes LINK_POLLY_INTO_TOOLS=ON builds, which previously failed with:
CMake Error: install(EXPORT "LLVMExports" ...) includes target "opt" which
requires target "Polly" that is not in the export set.
CMake Error: install(EXPORT "LLVMExports" ...) includes target "bugpoint" which
requires target "Polly" that is not in the export set.
llvm-svn: 222977
Remove the PoCC and ScopLib support from Polly as we do not have a
user/maintainer for it.
Differential Revision: http://reviews.llvm.org/D4871
llvm-svn: 215563
We only supported a very old version of OpenScop that was entirely different
to what OpenScop is today. To not confuse people, we remove this old and
unusable support. If anyone is interested to add OpenScop support back in,
the relevant patches are available in version control.
llvm-svn: 206026
The module LLVMPolly.so links to that. There is really no reason to build a
large number of mini-libraries here, especially as we do have dependences
between the libraries that are not properly handled and that make linking fail
on darwin.
Submitted-by: David Fang <fang@csl.cornell.edu>
llvm-svn: 202743
This change ensures that isl is only detected if it includes code generation
support. This allows us to remove a lot of conditional compilation and also
avoids missing test cases in case the feature is not available.
llvm-svn: 166403
Mateusz Mikuła