The LLVM tools can be used as a replacement for binutils, in which case
it's convenient to create symlinks with the binutils names. Add support
for these symlinks in the build system. As with any other llvm tool
symlinks, the user can limit the installed symlinks by only adding the
desired ones to `LLVM_TOOLCHAIN_TOOLS`.

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

llvm-svn: 317272

LLVM now requires a minimum of cmake 3.4.3, and all the policies
currently being set are present in that cmake version, so the
conditionals will always be true and are therefore unnecessary. The
movation is that the conditionals can give the false impression that the
policy settings are optional, whereas for example it's necessary to set
CMP0056 in order for `check_linker_flags` to operate correctly after
r316972. Inline the project version and language setting in the process.

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

llvm-svn: 317264

It's possible for multiple distribution components to have missing
targets, and it's a lot more convenient to get all those errors in one
shot rather than having to fix them individually.

llvm-svn: 317148

`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

LLVM checks if it is performing an in-source build and then stop the
build. However, this check is also triggered if LLVM is being build as
part of a parent project, which prevents the parent project itself from
using in-source builds. For example, CMake allows a parent project to
specify the output of its subproject:

add_subdirectory(llvm llvm_build)

This tells CMake to conduct an out-tree build of LLVM, which without
this patch will still fails because what is being tested is the parent
project, not LLVM. This is fixed by using the "CURRENT" variable, which
is only concerned by the CMakeLists that is actually bein processed at
the moment.

Tests:
Ran `make check-llvm`.

Patch by Henrique Jung <henriquenj_AT_gmail_DOT_com>

llvm-svn: 316142

We add /usr/local/include to the include directory list for some BSD
systems. We should mark this as a system directory to avoid files from
/usr/local/include getting picked over files shipping with llvm.

This typically manifested as gtest headers installed with the system
getting picked over the ones shipping with llvm.

Patch by Petr Penzin <penzin.dev@gmail.com>

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

llvm-svn: 315952

Ninja doesn't seem to recognize a change in a CMakeLists.txt in a
subdirectory, so r315861 is not having any effect.

llvm-svn: 315870

Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people.

Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1

llvm-svn: 315854

Reviewers: kcc, bogner

Reviewed By: bogner

Subscribers: mgorny, llvm-commits

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

llvm-svn: 315629

Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.

Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.

Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.

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

llvm-svn: 315590

Summary:
It appears polly makes use of the `CMAKE_RUNTIME_OUTPUT_DIRECTORY` variable
when configuring its lit test suite. Reverting this for now.

llvm-svn: 314551

Summary:
Three `CMAKE_.*_OUTPUT_DIRECTORY` variables used to be set in CMake and
referenced in various other parts of the project. However, in r198205
chapuni added a note to "don't set them anymore", and any remaining
references to them were subsequently removed in r198316 and r199592.

Now that the variables are no longer used anywhere, remove them, along
with the comments advising against using them any longer.

Test Plan:
I ran `check-all` and confirmed the tests built and passed.

Reviewers: beanz, chapuni

Reviewed By: beanz

Subscribers: mgorny

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

llvm-svn: 314550

Summary:
The typo was added in https://reviews.llvm.org/rL247151.
It should be "warning", not "wraning".

llvm-svn: 314486

Summary:
*In-source builds* of LLVM, in which a user invokes `cmake` from within the
LLVM source directory, or invokes `cmake -B/path/to/source/dir/of/llvm`,
are explicitly checked for and disallowed by LLVM's `CMakeLists.txt`.

*In-tree builds*, on the other hand, refer to when the source directories
of projects such as Clang are nested within the `llvm/tools` source
directory. These are not disallowed, and are in fact a common way of
building LLVM and Clang.

Revise the comment to match the logic underneath it: it checks for an
"in-source build", not an "in-tree build".

Reviewers: beanz

Reviewed By: beanz

Subscribers: mgorny

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

llvm-svn: 314348

always set LLVM_ENABLE_DUMP=ON for +Asserts builds.

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

llvm-svn: 314346

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

llvm-svn: 314186

This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its
tools with IR PGO instrumentation.

Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both
options must be enabled)

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

llvm-svn: 313770

This is a resubmission of r313270.  It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.

The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config.  If present, it
will generate llvm-lit into the output directory.  Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system.  This supports the use case of
someone installing lit via a package manager.  If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.

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

llvm-svn: 313407

This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.

llvm-svn: 313335

This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.

A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run.  However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on.  As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.

This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.

This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.

On the other hand, for us it allows us to make many simplifications:

* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
  might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
  on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
  support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
  finding a site config from the main config are now gone.

One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters.  Instead, you need to run
llvm-lit.py.

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

llvm-svn: 313270

This was intended to be a generic CMake solution to a problem
shared across several projects.  It turns out it doesn't interact
very well certain CMake configurations, and furthermore the
"problem" is actually not a problem, as the problematic code
is never executed to begin with.  So this really isn't solving
anything.

llvm-svn: 313191

Some projects need to add conditional dependencies on other projects.
compiler-rt is already doing this, and I attempted to add this to
debuginfo-tests when I ran into the ordering problem, that you can't
conditionally add a dependency unless that dependency's CMakeLists.txt
has already been run (which would allow you to say if (TARGET foo).

The solution to this seems to be to determine very early on the entire
set of projects which is enabled. This is complicated by the fact that
there are multiple ways to enable projects, and different tree layouts
(e.g. mono-repo, out of -tree, external, etc). This patch attempts to
centralize all of this into one place, and then updates compiler-rt to
demonstrate as a proof of concept how this can simplify code.

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

llvm-svn: 313091

Summary:
This reduces the number of build actions after a no-op commit from
thousands to about six, which should be acceptable. If six actions is
still too many, developers can disable the LLVM_APPEND_VC_REV cmake
option.

llvm-config.h is a widely included header that should rarely change.
Before this patch, it would change after every re-configure. Very few
users of llvm-config.h need to know the precise version, and those that
do can migrate to incorporating LLVM_REVISION as provided by
llvm/Support/VCSRevision.h.

This should bring LLVM back to the behavior that it had before r306858
from June 30 2017. Most LLVM tools will now print a version string like
"6.0.0svn" instead of "6.0.0-git-c40c2a23de4".

Fixes PR34308

Reviewers: pcc, rafael, hans

Subscribers: mgorny, llvm-commits

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

llvm-svn: 312043

It was mistakenly added to that list in D23560 (committed in rL285712). RISCV 
is an experimental backend and should never have been in that list, I 
mistakenly interpreted LLVM_ALL_TARGETS as a list of all targets rather than 
targets to build by default. Unfortunately, because of this the RISCV backend 
has been building by default when it shouldn't be.

This commet adds a description comment, which should help to avoid such 
mistakes in the future.

See my message to llvm-dev for more information and analysis 
<http://lists.llvm.org/pipermail/llvm-dev/2017-August/116347.html>.

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

llvm-svn: 310796

With this change, the GlobalISel library gets always built. In
particular, this is not possible to opt GlobalISel out of the build
using the LLVM_BUILD_GLOBAL_ISEL variable any more.

llvm-svn: 309990

This reverts r309602, check-lit still leaves Output directories in the
source directory.

llvm-svn: 309833

Summary:
This is an alternative solution to running the lit test suite on bots
without polluting the source directory. Each input test suite gets an
auto-generated site config in the build directory that points back to
the test input source directory.

This adds some cmake comlexity, but now we don't need to remove and
re-copy the test input directory before every test.

Reviewers: delcypher, modocache

Subscribers: mgorny, llvm-commits

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

llvm-svn: 309602

Summary:
Depends on https://reviews.llvm.org/D35879.

This reverts rL257268, which in turn was a revert of rL257221.
https://reviews.llvm.org/D35879 marks the tests in the lit test suite
that fail on Windows as XFAIL, which should allow these tests to pass
on Windows-based buildbots.

Reviewers: delcypher, beanz, mgorny, jroelofs, rnk

Reviewed By: mgorny

Subscribers: rnk, ddunbar, george.karpenkov, llvm-commits

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

llvm-svn: 309310

This gets rid of almost LLVM targets unconditionally depending on intrinsic_gen.

Clang's modules still have weird dependencies and hard to remove intrinsics_gen in better way.
Then, it'd be better to give whole clang targets depend on intrinsic_gen.

llvm-svn: 308844

Summary: Implement parsing and writing of a single xml manifest file.

Subscribers: mgorny, llvm-commits, hiraditya

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

llvm-svn: 308679

llvm-svn: 308442

The builder clang-x86_64-linux-selfhost-modules-2 complains. Investigating.

llvm-svn: 308439

I think modulemap is sufficient for intrinsics_gen in trunk. I won't find any issues around that.

llvm-svn: 308434

Summary:
This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils
that are installed when the LLVM_INSTALL_UTILS.  This option
defaults to 'bin' to remain consistent with the current behavior, but
distros may want to install these to libexec/llvm.

Reviewers: beanz

Reviewed By: beanz

Subscribers: llvm-commits, mgorny

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

llvm-svn: 307150

Working with git on a branch I find it really annoying that committing
a change causes ninja to think that stuff needs to be rebuilt.

With this change at least nothing in llvm needs to be rebuild when
something is committed.

llvm-svn: 306858

Summary:
Got rid of unwieldy -include Solaris.h portability solution, replacing it with interposed header and moving endian defines into Host.h.

Fixes PR28370.

Reviewers: joerg, alekseyshl, mgorny

Reviewed By: joerg

Subscribers: llvm-commits, mgorny, ro, krytarowski

Patch by Fedor Sergeev.

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

llvm-svn: 306002

llvm-svn: 305994

[CMake] Introduce LLVM_TARGET_TRIPLE_ENV as an option to override LLVM_DEFAULT_TARGET_TRIPLE at runtime.

No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.

If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.

Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;

  TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
  TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools

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

llvm-svn: 305632

Patch by David Abdurachmanov!

llvm-svn: 305123

Fixes embedded uses of llvm where google testing framework is provided outside.

llvm-svn: 305088