1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-19 02:52:53 +02:00
Commit Graph

1254 Commits

Author SHA1 Message Date
Shoaib Meenai
99b6e72b29 [cmake] Only attempt to install MSVC system libraries on Windows
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
2017-12-14 18:41:49 +00:00
Petr Hosek
922062820a [CMake] Pass LLVM_HAVE_LINK_VERSION_SCRIPT to external projects
Some external projects depend on this LLVM CMake variable.

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

llvm-svn: 320658
2017-12-13 23:49:51 +00:00
Shoaib Meenai
0d437ee4ce [cmake] Add support for case-sensitive Windows SDKs
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
2017-12-13 23:38:12 +00:00
Shoaib Meenai
0ebe73c608 [cmake] Support host architectures other than x64
Allow building for other architectures when cross-compiling for Windows.

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

llvm-svn: 320656
2017-12-13 23:12:38 +00:00
Shoaib Meenai
f9681785c2 [cmake] Explicitly set VS 2017 compatibility
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
2017-12-13 21:12:37 +00:00
Shoaib Meenai
ef9d2655ca [cmake] Determine MSVC host triple correctly when cross-compiling
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
2017-12-13 21:11:14 +00:00
Alex Bradbury
2383bfaf68 [cmake] Fix host tools build in when LLVM_EXPERIMENTAL_TARGETS_TO_BUILD is set
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
2017-12-13 09:02:13 +00:00
Justin Bogner
743ca2d884 [cmake] Pass TARGETS_TO_BUILD through to host tools build
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
2017-12-11 19:53:23 +00:00
Shoaib Meenai
153685d9e3 [cmake] Only pass CMAKE_SYSROOT if non-empty
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
2017-12-08 19:42:47 +00:00
Pavel Labath
fd8c611447 [cmake] Make setting of CMAKE_C(XX)_COMPILER flags overridable for cross-builds
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
2017-12-08 09:59:48 +00:00
Matt Morehouse
5ec2b2d7ea [CMake] Use PRIVATE when linking LLVM fuzzers.
More fuzzers missed by r319840.

llvm-svn: 319987
2017-12-06 23:32:46 +00:00
Shoaib Meenai
b8543cbaec [cmake] Remove unnecessary header include in atomics check
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
2017-12-06 18:33:07 +00:00
Don Hinton
53cb4a8f16 [cmake] Move CMAKE_(C|CXX)_COMPILER variables before CROSS_TOOLCHAIN_FLAGS so
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
2017-12-06 15:25:14 +00:00
Shoaib Meenai
d81bfe1cb8 [CMake] Use PRIVATE in target_link_libraries for executables
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
2017-12-05 21:49:56 +00:00
Pavel Labath
d9438e5fb6 Re-commit "[cmake] Enable zlib support on windows"
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
2017-12-05 10:24:15 +00:00
Shoaib Meenai
54283334f4 [cmake] Modernize some conditionals. NFC
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
2017-12-05 01:19:48 +00:00
Petr Hosek
3f97323c09 [CMake] Don't use comma as an alternate separator
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
2017-12-05 00:15:18 +00:00
Pavel Labath
1431200847 Revert "[cmake] Enable zlib support on windows"
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
2017-12-04 16:46:20 +00:00
Don Hinton
2486515d54 [cmake] Re-commit: Remove redundant call to cmake when building host tools.
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
2017-12-02 19:12:38 +00:00
Martell Malone
34f65497f3 CMAKE: help CheckAtomic find check_library_exists
lldb fails to build standalone on x86

-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed
CMake Error at CheckAtomic.cmake:66 (check_library_exists):
  Unknown CMake command "check_library_exists".
Call Stack (most recent call first):
  LLDBStandalone.cmake:90 (include)
CMakeLists.txt:3 (include)

Reviewed By: rnk

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

llvm-svn: 319610
2017-12-02 07:17:01 +00:00
Don Hinton
7a5e0ca76a [cmake] Revert (rL319574): Resubmit Remove redundant call to cmake when building host tools.
Still fails for some bots.

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

llvm-svn: 319582
2017-12-01 20:46:45 +00:00
Don Hinton
80dbb16b69 [cmake] Resubmit Remove redundant call to cmake when building host tools.
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
2017-12-01 19:35:56 +00:00
Pavel Labath
e4b98ce2bf [cmake] Enable zlib support on windows
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
2017-12-01 11:41:07 +00:00
Adam Nemet
e923ea8387 [cmake] Expose opt-viewer availability
This will be used in https://github.com/apple/swift/pull/12938

llvm-svn: 319511
2017-12-01 01:44:26 +00:00
Shoaib Meenai
bb1b6ae244 [llvm] Add stripped installation targets
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
2017-11-30 21:48:26 +00:00
Michal Gorny
f0ba71f375 [cmake] Include project name in Sphinx doctree dir to fix race conditions
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
2017-11-30 19:09:22 +00:00
Greg Bedwell
5c717562d9 [cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases -Weverything
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
2017-11-29 18:05:32 +00:00
Adam Nemet
2885645683 Add opt-viewer testing
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
2017-11-29 17:07:41 +00:00
Don Hinton
f2169e2887 Rollback r319176.
The ';' separators in LLVM_TARGETS_TO_BUILD disappear when list
variables are evaluated in custom commands.

llvm-svn: 319268
2017-11-29 00:47:16 +00:00
Adam Nemet
a8d567ec8e Revert "Add opt-viewer testing"
This reverts commit r319188.

Breaks when c++filt is not available.

llvm-svn: 319262
2017-11-29 00:10:48 +00:00
Don Hinton
57f9a6b164 [cmake] Pass LLVM_USE_LINKER flag when building host tools, e.g.,
LLVM_OPTIMIZED_TABLEGEN=ON, and not crosscompiling.

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

llvm-svn: 319228
2017-11-28 21:23:30 +00:00
Adam Nemet
206e1448f6 Add opt-viewer testing
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

llvm-svn: 319188
2017-11-28 17:26:28 +00:00
Don Hinton
921e884d63 [cmake] Remove redundant call to cmake when building host tools.
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
2017-11-28 16:08:57 +00:00
Adam Nemet
b6f770f3e1 Revert "Add opt-viewer testing"
This reverts commit r319073.

Bot fails with a mismatch that looks like pygments-generated HTML.

llvm-svn: 319146
2017-11-28 06:22:29 +00:00
Petr Hosek
8403231ff6 [CMake] Pass LLVM_HOST_TRIPLE to external projects
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
2017-11-27 22:50:48 +00:00
Michal Gorny
6d3f09db6e [cmake] Pass -Wl,-z,nodelete on Linux to prevent unloading
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
2017-11-27 22:23:09 +00:00
Petr Hosek
392075da95 Use LIST_SEPARATOR rather than escaping in ExternalProject_Add
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
2017-11-27 20:41:53 +00:00
Michal Gorny
a44f44431c Revert r319069 - [cmake] Pass -Wl,-z,nodelete on Linux to prevent unloading
This breaks one of the unit tests. Need to find a good solution.

llvm-svn: 319076
2017-11-27 19:18:36 +00:00
Adam Nemet
fed86d9004 Add opt-viewer testing
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

llvm-svn: 319073
2017-11-27 19:00:29 +00:00
Michal Gorny
b87f043543 [cmake] Pass -Wl,-z,nodelete on Linux to prevent unloading
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
2017-11-27 18:34:52 +00:00
Michal Gorny
7022878f08 [CMake] Allow for Solaris ld -V output on stdout
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
2017-11-17 17:12:14 +00:00
Daniel Sanders
f521e30212 [globalisel][tablegen] Generate rule coverage and use it to identify untested rules
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
2017-11-16 00:46:35 +00:00
Hans Wennborg
da29bc5094 CMake: Turn LLVM_ENABLE_LIBXML2 into a tri-state option
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
2017-11-14 22:32:49 +00:00
Greg Bedwell
63d0385262 Move the setting of LLVM_BUILD_MODE to a macro so that we can re-use it in compiler-rt
Differential Revision: https://reviews.llvm.org/D38470

llvm-svn: 318034
2017-11-13 12:40:05 +00:00
Zachary Turner
d7b0abacde Add a Cross-compilation toolchain file for MSVC.
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
2017-11-09 20:38:16 +00:00
Petr Hosek
1db1a2d7be [CMake] Passthrough CMAKE_SYSROOT to external projects
Differential Revision: https://reviews.llvm.org/D39029

llvm-svn: 317744
2017-11-09 00:21:29 +00:00
Vedant Kumar
fe4076e8d8 [cmake] Allow LLVM_BUILD_INSTRUMENTED to be set to IR or Frontend
- 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
2017-11-08 21:26:40 +00:00
Jonas Hahnfeld
66e8748478 [CMake] Remove target to build native tablegen
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
2017-11-08 14:31:54 +00:00
Jonas Hahnfeld
7f7450de0d [CMake] Add custom target to create build directory
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
2017-11-08 14:31:51 +00:00
Hans Wennborg
698effca78 Revert r316064 "Fix the incorrect detection of ICONV_LIBRARY_PATH"
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
2017-11-06 22:17:23 +00:00