When building out-of-tree compilers (e.g. swift), the linker check here
may yield incorrect values. Ensure that we are using lld before we
attempt to use `--color-diagnostics` for the linker. Other linkers (i.e
bfd, gold) do not support this flag and the test can pass in some cases
and then fail subsequently when building.
llvm-svn: 330158
Summary:
[llvm-exegesis][RFC] Automatic Measurement of Instruction Latency/Uops
This is the code corresponding to the RFC "llvm-exegesis Automatic Measurement of Instruction Latency/Uops".
The RFC is available on the LLVM mailing lists as well as the following document
for easier reading:
https://docs.google.com/document/d/1QidaJMJUyQdRrFKD66vE1_N55whe0coQ3h1GpFzz27M/edit?usp=sharing
Subscribers: mgorny, gchatelet, orwant, llvm-commits
Differential Revision: https://reviews.llvm.org/D44519
llvm-svn: 329156
These used to be set in the old autoconf build, but the cmake build has had a
"TODO: actually check for these" comment since it was checked in, and they
were set to 1 on mingw unconditionally. It seems safe to say that they always
exist under mingw, so just remove them and assume they're set exactly when on
mingw (with msvc, we use `pragma comment` instead of linking these via flags).
llvm-svn: 328992
The autoconf manual: "This macro is obsolescent, as all current systems with
directory libraries have <dirent.h>. New programs need not use this macro."
llvm-svn: 328989
These should exist in all toolchains LLVM supports nowadays.
Enables making DataTypes.h a regular header instead of a .h.cmake file and
allows deleting a bunch of cmake goop (which should also speed up cmake
configure time a bit).
All the code this removes is 9+ years old.
https://reviews.llvm.org/D45155
llvm-svn: 328970
Found by looking through the output of
for f in $(grep -o '\bHAVE_[A-Z0-9_]*\b' llvm/cmake/config-ix.cmake); do
echo $f $(git grep $f '*' | wc -l);
done
in the monorepo.
llvm-svn: 328957
Summary:
As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version.
Like patch https://reviews.llvm.org/D41808, I propose that we rename libLLVM-7.0svn.so to libLLVM-7svn.so
This patch will also rename downstream libraries like liblldb-7.0 to liblldb-7
Reviewers: axw, beanz, dim, hans
Reviewed By: dim, hans
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D41869
llvm-svn: 328768
Cmake function llvm_check_source_file_list currently only accepts paths
relative to current CMAKE_SOURCE_DIR or relative to argument SOURCE_DIR.
Extend it to accept any path, including absolute ones.
Differential revision: https://reviews.llvm.org/D44625
llvm-svn: 327912
Summary:
This is needed so that external projects (e.g. a standalone build of
lldb) can link to the LLVM shared library via the USE_SHARED argument of
llvm_config. Without this, llvm_config would add LLVM to the link list,
but then also add the constituent static libraries, resulting in
multiply defined symbols.
Reviewers: beanz, mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44391
llvm-svn: 327484
Summary: Build system changes for RISCV. Makes it possible to build just the RISCV target alone.
Reviewers: asb, apazos, mgrang, beanz
Reviewed By: asb
Subscribers: mgorny, kito-cheng, shiva0217, llvm-commits
Differential Revision: https://reviews.llvm.org/D44153
llvm-svn: 327423
Append -Wl,-rpath-link conditionally to whether GNU ld.bfd is used
rather than the Linux+!gold conditionals. Also move it out of 'else'
branch of *BSD handling. This fixes build failures with ld.bfd
on Gentoo/FreeBSD, and should cause no harm on other systems using
ld.bfd.
This patch improves the original logic by reusing results of linker
detection introduced in r307852.
Differential Revision: https://reviews.llvm.org/D43751
llvm-svn: 327007
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
This re-commit fixes a missing include of <vector> which it seems clang didn't
mind but G++ and MSVC objected to. It seems that, clang was ok with std::vector
only being forward declared at the point of use since it was fully defined
eventually but G++/MSVC both rejected it at the point of use.
llvm-svn: 326738
Despite building cleanly on my machine in three separate configs, it's failing on pretty much all bots due to missing includes among other things. Investigating.
llvm-svn: 326726
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
llvm-svn: 326723
Introduce the LLVM_ENABLE_PDB option so that users can request them
explicitly instead.
Add /OPT:REF and /OPT:ICF back, which /DEBUG disables by default.
Differential Revision: https://reviews.llvm.org/D43156
llvm-svn: 325296
This patch enables PDB generation for Release build, which has
slightly different optimize option with RelWithDebInfo on windows.
This helps to know slow part of Release build when profiling.
Patch by Takuto Ikuta
Differential Revision: https://reviews.llvm.org/D42632
llvm-svn: 324504
Summary:
Rename LLVM_CONFIG_EXE to LLVM_CONFIG_PATH, and avoid building it if
passed in by user. This is the same way CLANG_TABLEGEN and
LLVM_TABLEGEN are handled, e.g., when -DLLVM_OPTIMIZED_TABLEGEN=ON is
passed.
Differential Revision: https://reviews.llvm.org/D41806
llvm-svn: 323053
Include the LLVM_LIBXML2_ENABLED cache variable in LLVMConfig.cmake
in order to make it available for other LLVM packages to query. This
is necessary to fix stand-alone testing of LLD.
Differential Revision: https://reviews.llvm.org/D42252
llvm-svn: 322973
Summary:
Currently LLVM has no way to support configuring for IDE's like CLion. Like XCode and MSVC's IDE, CLion needs to see all of the headers and tablegen files in order to properly parse the sources.
This patch adds an `LLVM_ENABLE_IDE` option which can be used to configure for IDE's in general. It is used by `LLVMProcessSources.cmake` to determine if the extra source files should be added to the target.
Unfortunately because of the low level of `LLVMProcessSources.cmake`, I'm not sure where the `LLVM_ENABLE_IDE` option should live. I choose `HandleLLVMOptions.cmake` so that out-of-tree Clang builds would correctly configure the option by default.
Reviewers: beanz, mgorny, lebedev.ri
Reviewed By: beanz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40219
llvm-svn: 322349
When cross-compiling for Windows on Unix, the built toolchain will need
to be transferred to Windows to actually run. My opinion is that the
Unix build should use symlinks, and the transfer to Windows should take
care of making those symlinks usable. E.g., I envision tarballs to be a
common form of transfer from Unix to Windows, in which case the tarball
can be created using --dereference to follow the symlinks.
The motivation here is that, when cross-compiling for Windows on Unix,
the installation will *already* create symlinks. The reason is that the
installation script will be invoked without knowing the host system, so
the `if(UNIX)` check in the installation symlink creation script will
reflect the build system rather than the host system. We could either
make the build and install trees both contain copies or both contain
symlinks, and using symlinks is a significant space saving without (in
my opinion) having any detrimental effect on the usage of the cross-
compiled toolchain on Windows.
A secondary motivation is that Windows 10 version 1703 and later finally
lift the administrator rights requirement for creating symbolic links
(if the system is in Developer Mode), which makes symlinks a lot more
practical even on Windows. Of course Unix and Windows symlinks aren't
interoperable, but symlinks for Windows toolchains is a reasonable
future direction to be going in anyway.
Differential Revision: https://reviews.llvm.org/D41314
llvm-svn: 322061
When cross-compiling, we cannot use the just built toolchain, instead
we need to use the host toolchain which we assume has a support for
targeting the selected target platform. We also need to pass the path
to the native version of llvm-config to external projects.
Differential Revision: https://reviews.llvm.org/D41678
llvm-svn: 322046
If the make program isn't in the path, the native configure will fail.
Pass CMAKE_MAKE_PROGRAM to the native configure explicitly to remedy
this, similar to what's already done for external project configuration.
Explicitly set CMAKE_MAKE_PROGRAM before the user flags so that they can
override it for the native build if they desire (though I can't fathom
why that would be useful).
llvm-svn: 322032
Some systems still don't have this module which was introduced in
version 2.0 (CentOS 7, sigh).
Differential Revision: https://reviews.llvm.org/D41611
llvm-svn: 321659
Summary:
Always respect existing CMAKE_REQUIRED_FLAGS when adding
additional ones. This is important when cross compiling where
--sysroot and -target were already added.
In particular, this is needed when cross compiling from Darwin to
Linux, since --sysroot is required to find headers and libraries.
Cmake has a similar bug in check_include_file[_cxx] where
CMAKE_REQUIRED_LIBRARIES isn't passed, which causes
try_compile to fail.
(please see https://gitlab.kitware.com/cmake/cmake/merge_requests/1620)
Reviewers: compnerd, silvas, beanz, brad.king
Reviewed By: compnerd
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D41568
llvm-svn: 321434
macOS paths usually start with /Users, which clang-cl interprets as a
macro undefine, leading to pretty much everything failing to compile.
CMake should be taught to put a -- in its compilation rules for clang-cl
(and I've been meaning to submit that upstream for a while). In the
meantime, however, and to support older CMake versions, we can just
create a custom make rules override to fix the compilation rules.
Differential Revision: https://reviews.llvm.org/D41219
llvm-svn: 320785
Newer versions of CMake (I'm on 3.10, but I believe 3.9 behaves the same
way) attempt to query the system for information about the VS 2017
install. Unfortunately, this query fails on non-Windows systems:
cmake_host_system_information does not recognize <key> VS_15_DIR
CMake isn't going to find these system libraries on non-Windows anyway
(and we were previously silencing the resultant warnings in our
cross-compilation toolchain), so it makes sense to just omit the
attempted installation entirely on non-Windows.
Differential Revision: https://reviews.llvm.org/D41220
llvm-svn: 320724
When the Windows SDK is hosted on a case-sensitive filesystem (e.g. when
compiling on Linux and not using ciopfs), we can automatically generate
a VFS overlay for headers and symlinks for libraries.
Differential Revision: https://reviews.llvm.org/D41156
llvm-svn: 320657
When cross-compiling using clang-cl 5.0 (which is currently the latest
stable release of the compiler), the default MS compatibility level is
set to VS 2013, which is too low to build LLVM. Explicitly set the
compatibility level to VS 2017 to support cross-compiling LLVM for
Windows using clang-cl 5.0. This will be a no-op when using clang-cl 6.0
and above, where the default MS compatibility level is already VS 2017.
Differential Revision: https://reviews.llvm.org/D41157
llvm-svn: 320616
CMAKE_CL_64 will never be set when cross-compiling with clang-cl, since
CMake relies on an actual VS environment in order to determine it.
Instead, use the size of a void pointer to determine the bit width of
the host compiler (and therefore the host triple), which works for both
native and cross compilation.
Note that, with the impending advent of Windows on AArch64, assuming
that a 64-bit host == x86_64 isn't correct either, but that's something
to be addressed in a follow-up.
Differential Revision: https://reviews.llvm.org/D41155
llvm-svn: 320615
r320413 triggered cmake configure failures when building with
-DLLVM_OPTIMIZED_TABLEGEN=True and with LLVM_EXPERIMENTAL_TARGETS_TO_BUILD set
(e.g. to RISCV). This is because that patch moved to passing through
LLVM_TARGETS_TO_BUILD, and at that point LLVM_EXPERIMENTAL_TARGETS_TO_BUILD
has been merged in to it. LLVM_EXPERIMENTAL_TARGETS_TO_BUILD must be also be
passed through to avoid errors like below:
-- Constructing LLVMBuild project information
CMake Error at CMakeLists.txt:682 (message):
The target `RISCV' does not exist.
It should be one of
AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;X86;XCore
-- Configuring incomplete, errors occurred!
See the thread
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171211/509225.html
for discussion of this fix.
llvm-svn: 320556
In r319620, the host build was changed to use Native for
TARGETS_TO_BUILD because passing semicolons through add_custom_command
is surprisingly difficult. However, Native really doesn't make any
sense here, and it only works because we don't technically do any
codegen in the host tools so pretty well anything will "work".
The problem here is that passing something other than the correct
value is very fragile - as evidence note how the llvm-config in the
host tools acts differently than the target one now, and misreports
the targets to build. Similarly, if there is any logic conditional on
the targets in tablegen (now or in the future), it will do the wrong
thing.
To fix this, we need to escape the semicolons in the targets string
and pass it through to the child cmake invocation.
llvm-svn: 320413
In my build environment (cmake 3.6.1 and gcc 4.8.5 on CentOS 7), having
an empty CMAKE_SYSROOT in the cache results in --sysroot="" being passed
to all compile commands, and then the compiler errors out because of the
empty sysroot. Only set CMAKE_SYSROOT if non-empty to avoid this.
Differential Revision: https://reviews.llvm.org/D40934
llvm-svn: 320183
Summary:
r319898 made it possible to override these variables via the
CROSS_TOOLCHAIN_FLAGS setting, but this only worked if one explicitly
specifies these variables there. If, instead, one uses
CROSS_TOOLCHAIN_FLAGS to specify a toolchain file (as our internal
builds do, to point cmake to a checked-in toolchain), the
CMAKE_C(XX)_COMPILER flags would still win over the ones specified by
the toolchain file.
To fix is to make the mere presence of these flags overridable. I do
this by putting them as a default value for the CROSS_TOOLCHAIN_FLAGS
setting, so they can be overridden at cmake configuration time.
Reviewers: hintonda, beanz
Subscribers: bogner, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D40947
llvm-svn: 320138
The header include was required to work around PR19898, as noted in that
comment. That PR has since been marked resolved fixed, and the
configuration check passes without the header inclusion both when
compiling on Windows with cl and when cross-compiling on Linux using
clang-cl.
I noticed this because the inclusion was cased incorrectly (Intrin.h
instead of intrin.h), which when cross-compiling on a case sensitive
file system would cause the intrin.h from the Windows SDK to be included
(which LLVM can't handle) instead of the one from clang's resource
directory, making the check fail. This is the same issue as r309980.
Correcting the case of the inclusion makes the check pass when cross
compiling, but it seems better to get rid of the inclusion entirely,
since it appears to be unnecessary now.
Differential Revision: https://reviews.llvm.org/D40910
llvm-svn: 319917
they can be overridden when cross compiling.
Summary:
Since CROSS_TOOLCHAN_FLAGS can set CMAKE_(C|CXX)_COMPILER
variables, move the compiler variables up front so they can be
overridden.
This is a followup to https://reviews.llvm.org/D40229 committed in rL319620.
Thanks to Pavel Labath for reporting this issue.
Reviewers: labath, beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D40896
llvm-svn: 319898
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
This recommits r319533 which was broken llvm-config --system-libs
output. The reason was that I used find_libraries for searching for the
z library. This returns absolute paths, and when these paths made it
into llvm-config, it made it produce nonsensical flags. To fix this, I
hand-roll a search for the library in the same way that we search for
the terminfo library a couple of lines below.
This is a bit less flexible than the find_library option, as it does not
allow the user to specify the path to the library at configure time
(which is important on windows, as zlib is unlikely to be found in any
of the standard places cmake searches), but I was able to guide the
build to find it with appropriate values of LIB and INCLUDE environment
variables.
Reviewers: compnerd, rnk, beanz, rafael
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D40779
llvm-svn: 319751
The "x${...}" form was a workaround for CMake versions prior to 3.1,
where the if command would interpret arguments as variables even when
quoted [1]. We can drop the workaround now that our minimum CMake
version is 3.4.
[1] https://cmake.org/cmake/help/v3.1/policy/CMP0054.html
Differential Revision: https://reviews.llvm.org/D40744
llvm-svn: 319723
Using comma can break in cases when we're passing flags that already
use comma as a separator.
Fixes PR35504.
Differential Revision: https://reviews.llvm.org/D40761
llvm-svn: 319719
This reverts commit r319533 as it broke llvm-config --system-libs output
and everything that depends on it (which is mostly out of tree or
downstream folks, but includes a couple of llvm buildbots as well).
I think I have a fix for this in D40779, but I want someone to look
review it first. In the mean time, I am reverting this change, as it
seems to break a lot of people.
llvm-svn: 319663
Also pass CMAKE_(C|CXX)_COMPILER to add_custom_command.
Summary:
Remove the redundant, config-time call to cmake when
building host tools for cross compiles or optimized tablegen..
The config-time call to cmake is redundant because it will always get
called again when the CONFIGURE_LLVM_${target_name} target fires at
build-time. This speeds up initial configuration, but has no affect
on build behavior.
Differential Revision: https://reviews.llvm.org/D40229
llvm-svn: 319620
Only pass Native to LLVM_TARGETS_TO_BUILD.
Summary:
Remove the redundant, config-time call to cmake when
building host tools for cross compiles or optimized tablegen..
The config-time call to cmake is redundant because it will always get
called again when the CONFIGURE_LLVM_${target_name} target fires at
build-time. This speeds up initial configuration, but has no affect
on build behavior.
Differential Revision: https://reviews.llvm.org/D40229
llvm-svn: 319574
Summary:
zlib support was hard-wired to off for (non-cygwin) windows targets.
This disables some features, such as reading debug info from compressed
dwarf sections.
This has been this way since zlib support was added in 2013 (r180083),
but there is no obvious reason for that. Zlib is perfectly capable of
being compiled for windows (it even has a cmake file that works out of
the box).
This enables one to turn on zlib support on windows, if one has zlib
avaliable.
Reviewers: rnk, beanz
Subscribers: mgorny, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D40655
llvm-svn: 319533
CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP`
to enable stripping the installed binaries. LLVM's build system doesn't
expose this option to the `install-` targets, but it's useful in
conjunction with `install-distribution`.
Add a new function to create the install targets, which creates both the
regular install target and a second install target that strips during
installation. Change the creation of all installation targets to use
this new function. Stripping doesn't make a whole lot of sense for some
installation targets (e.g. the LLVM headers), but consistency doesn't
hurt.
I'll make other repositories (e.g. clang, compiler-rt) use this in a
follow-up, and then add an `install-distribution-stripped` target to
actually accomplish the end goal of creating a stripped distribution. I
don't want to do that step yet because the creation of that target would
depend on the presence of the `install-*-stripped` target for each
distribution component, and the distribution components from other
repositories will be missing that target right now.
Differential Revision: https://reviews.llvm.org/D40620
llvm-svn: 319480
Modify add_sphinx_target() to include the project name alongside builder
in Sphinx doctree directory. This aims to avoid crashes due to race
conditions between multiple Sphinx instances running in parallel that
attempt to create or read that directory simultaneously.
This problem has originally been addressed in r283188. However, that
commit presumed that there will be only one target per builder being
run. However, r314863 introduced a second manpage target, reintroducing
the race condition.
Differential Revision: https://reviews.llvm.org/D40656
llvm-svn: 319461
Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl
aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall
previously aliased.
This should restore the verbosity of a Windows selfhost build back to
its previous levels.
Differential Revision: https://reviews.llvm.org/D40603
llvm-svn: 319330
Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.
This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).
It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.
Differential Revision: https://reviews.llvm.org/D40202
Fixes since the first commit:
1. Disable syntax highlighting as different versions of pygments generate
different HTML
2. Use llvm-cxxfilt from the build
llvm-svn: 319324
Summary:
Remove the redundant, config-time call to cmake when
building host tools for cross compiles or optimized tablegen..
The config-time call to cmake is redundant because it will always get
called again when the CONFIGURE_LLVM_${target_name} target fires at
build-time. This speeds up initial configuration, but has no affect
on build behavior.
Reviewers: beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D40229
llvm-svn: 319176
LLVM runtimes rely on LLVM_HOST_TRIPLE being set in their builds
and tests so make sure it's being passed down.
Differential Revision: https://reviews.llvm.org/D40515
llvm-svn: 319109
Prevent unloading shared libraries on Linux when dlclose() is called.
This is necessary since command-line option parsing API relies on
registering the global option instances in the option parser instance
which can be loaded in a different shared library.
Given that we can't reliably remove those options when a library is
unloaded, the parser ends up containing dangling references. Since glibc
has relatively complex library unloading rules, some of the LLVM
libraries can be unloaded while others (including the Support library)
stay loaded causing quite a mayhem. To reliably prevent that, just
forbid unloading all libraries -- it's a very bad idea anyway.
While the issue arguably happens only with BUILD_SHARED_LIBS, it may
affect any library reusing llvm::cl interface.
Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154.
Previously hit by Fedora back in Feb 2016:
https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html
Differential Revision: https://reviews.llvm.org/D40459
llvm-svn: 319105
Escaping ; in list arguments passed to ExternalProject_Add doesn't seem
to be working in newer versions of CMake (see
https://public.kitware.com/Bug/view.php?id=16137 for more details). Use
a custom LIST_SEPARATOR instead which is the officially supported way.
Differential Revision: https://reviews.llvm.org/D40232
llvm-svn: 319089
Prevent unloading shared libraries on Linux when dlclose() is called.
This is necessary since command-line option parsing API relies on
registering the global option instances in the option parser instance
which can be loaded in a different shared library.
Given that we can't reliably remove those options when a library is
unloaded, the parser ends up containing dangling references. Since glibc
has relatively complex library unloading rules, some of the LLVM
libraries can be unloaded while others (including the Support library)
stay loaded causing quite a mayhem. To reliably prevent that, just
forbid unloading all libraries -- it's a very bad idea anyway.
While the issue arguably happens only with BUILD_SHARED_LIBS, it may
affect any library reusing llvm::cl interface.
Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154.
Previously hit by Fedora back in Feb 2016:
https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html
Differential Revision: https://reviews.llvm.org/D40459
llvm-svn: 319069
In recent versions of Solaris 11.4 (previously 12), ld -V output went to
stdout instead of stderr. Since AddLLVM.cmake only expects it on stderr,
Solaris ld wasn't properly detected and options not understood by it are
passed during the build.
The following patch fixes this, allowing for both variants.
Tested on i386-pc-solaris2.11.4 (on top of D35755 which is needed for
proper Solaris support).
Patch by Rainer Orth.
Differential Revision: https://reviews.llvm.org/D39601
llvm-svn: 318532
Summary:
This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV,
causes TableGen to instrument the generated table to collect rule coverage
information. However, LLVM_ENABLE_GISEL_COV goes a bit further than
LLVM_ENABLE_DAGISEL_COV. The information is written to files
(${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be
concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will
read this information and use it to emit warnings about untested rules.
This technique could also be used by SelectionDAG and can be further
extended to detect hot rules and give them priority over colder rules.
Usage:
* Enable LLVM_ENABLE_GISEL_COV in CMake
* Build the compiler and run some tests
* cat gisel-coverage-[0-9]* > gisel-coverage-all
* Delete lib/Target/*/*GenGlobalISel.inc*
* Build the compiler
Known issues:
* ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual
step due to a lack of a portable 'cat' command. It should be the
concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files.
* There's no mechanism to discard coverage information when the ruleset
changes
Depends on D39742
Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka
Reviewed By: rovka
Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D39747
llvm-svn: 318356
In addition to the current ON and OFF options, this adds the FORCE_ON
option, which causes a configuration error if libxml2 cannot be used.
Differential revision: https://reviews.llvm.org/D40050
llvm-svn: 318209
With this patch, you can now cross-compile for Windows
on non-Windows hosts.
Differential Revision: https://reviews.llvm.org/D39814
This allows cross-compiling for windows on other platforms.
llvm-svn: 317830
- This deprecates LLVM_ENABLE_IR_PGO but keeps it around for now.
- Errors out when LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE
are both set.
Motivated by bogner's post-commit review of r313770.
llvm-svn: 317725
This was once needed so that multiple tablegen binaries don't compile
the library concurrently. However, this isn't needed anymore since
adding USES_TERMINAL to the custom_command.
This is supported by the fact that the target was only building
LLVMSupport since some cleanups a year ago. If this dependency had
really been needed, we would have seen complaints.
Differential Revision: https://reviews.llvm.org/D39299
llvm-svn: 317695
CMake does a poor job in tracking dependencies on files and directories
directly. Create custom target similar to the configuration step.
On my system, this avoids the reconfiguration on each build.
Differential Revision: https://reviews.llvm.org/D39298
llvm-svn: 317694
This broke the use of libxml2 on machines where iconv() is provided by libc.
I'll follow up on the mailing list to discuss how to fix this properly.
> This is introduced in rL308711.
> Check for c library is incorrect here just because libc will be found always
> and it does not mean that iconv is presented.
>
> Thank to Andrew Krasny for narrowing down the root cause.
>
> Reviewers: ecbeckmann
> Reviewed By: ecbeckmann
> Subscribers: mgorny, llvm-commits
> Differential Revision: https://reviews.llvm.org/D38875
llvm-svn: 317517
`check_linker_flags` currently sets the *compiler* flags (via
`CMAKE_REQUIRED_FLAGS`), and thus implicitly relies on cmake's default
behavior of passing the compiler flags to the linker. This breaks when
cmake's build rules have been altered to not pollute the link line with
compiler flags (which can be desirable for build cleanliness). Instead,
set `CMAKE_EXE_LINKER_FLAGS` explicitly and use `CMP0056` to ensure the
linker flags are passed along. Additionally, since we're inside a
function, we can just alter the variable directly (as the alteration
will be limited to the scope of the function) rather than saving and
restoring the old value.
Differential Revision: https://reviews.llvm.org/D39431
llvm-svn: 316972
check_cxx_compiler_flag doesn't seem to try to link a program, so
the existing code doesn't correctly detect the availability of a given
linker. This patch uses check_cxx_source_compiles instead.
I confirmed that cmake now reports this error
Host compiler does not support '-fuse-ld=foo'
for -DLLVM_USE_LINKER=foo.
Differential Revision: https://reviews.llvm.org/D39274
llvm-svn: 316958
Fix linker not being correctly detected when a custom one is specified
through LLVM_USE_LINKER CMake variable.
In particular,
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold ../llvm
resulted into
Linker detection: GNU ld
instead of
Linker detection: GNU Gold
due to the construction not accounting for such variable. It led to the general
confusion and prevented setting linker-specific flags inside functions defined
in AddLLVM.cmake.
Thanks Oleksii Vilchanskyi for the patch!
llvm-svn: 316956
gtest depends on this #define to determine whether it can
use various classes like std::tuple, or whether it has to fall
back to experimental classes in the std::tr1 namespace. The
check in the current version of gtest relies on the value of
the `__cplusplus` macro, but MSVC provides a non-conformant
value of this macro, making it effectively impossible to detect
C++11. In short, LLVM compiled with MSVC has been silently
using the tr1 versions of several classes since the beginning of
time.
This would normally be pretty benign, except that in the latest
preview of MSVC they have marked all of the tr1 classes
deprecated, so it spews thousands of warnings.
llvm-svn: 316798
Original commit message:
"[cmake] Use find_package to discover zlib
This allows us to use standard cmake utilities to point to non-system zlib
locations.
Patch by Oksana Shadura and me (D39002)."
The new patch brings back the old behavior in the cases where find_package
cannot find zlib.
llvm-svn: 316150
This is introduced in rL308711.
Check for c library is incorrect here just because libc will be found always
and it does not mean that iconv is presented.
Thank to Andrew Krasny for narrowing down the root cause.
Reviewers: ecbeckmann
Reviewed By: ecbeckmann
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38875
llvm-svn: 316064
This allows lld-link to process /manifestinput: flags on macOS too.
Also makes the `REQUIRES: manifesttool` lld tests run on macOS.
Setting LLVM_ENABLE_LIBXML2 to off can suppress this behavior, like on Linux.
llvm-svn: 315873
But now include a check for CPU_COUNT so we still build on 10 year old
versions of glibc.
Original message:
Use sched_getaffinity instead of std:🧵:hardware_concurrency.
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314931
Saleem Abdulrasool