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
Summary:
This reverts D38481. The change breaks systems with older versions of glibc. It
injects a use of CPU_COUNT() from sched.h without checking to ensure that the
function exists first.
Reviewers:
Subscribers:
llvm-svn: 314922
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: 314809
