Introduces the LLVM_CCACHE_PARAMS cmake variable, which can be used to
pass arbitrary parameters to ccache invocations.

llvm-svn: 324779

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

llvm-svn: 324570

It looks like this hasn't been updated since bugzilla moved.

Patch by Colden Cullen.

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

llvm-svn: 323457

Set cmake policy CMP0068=NEW, if available, and set
"CMAKE_BUILD_WITH_INSTALL_NAME_DIR=On" globally to
maintain current behavior.

This is needed to suppress warnings on OSX starting with cmake version
3.9.6.

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

llvm-svn: 323404

Patch by Matthew Davis!

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

llvm-svn: 323357

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

llvm-svn: 322959

llvm-svn: 321712

Summary:
Update this error message indicate this test only ensures experimental
targets were passed via LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.

Originally, this test validated all targets, but in r184923, it was moved
after the LLVMBUILDTOOL test, which also validates all targets, making
that part of the test redundant.

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

llvm-svn: 321012

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

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

llvm-svn: 320497

This is identical to the install-distribution target, except that it
strips the installed binaries.

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

llvm-svn: 320184

Summary: Make LLVM_ENABLE_DUMP independent LLVM_ENABLE_ASSERTIONS,
move it to llvm-config.h, and update description.

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

llvm-svn: 320111

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

This is still breaking greendragon.

At this point I give up until someone can fix the greendragon
bots, and I will probably abandon this effort in favor of using
a private github repository.

llvm-svn: 318722

This was reverted due to the tests being run twice on some
build bots.  Each run had a slightly different configuration
due to the way in which it was being invoked.  This fixes
the problem (albeit in a somewhat hacky way).  Hopefully in
the future we can get rid of the workflow of running
debuginfo-tests as part of clang, and then this hack can
go away.

llvm-svn: 318697

This is still broken because it causes certain tests to be
run twice with slightly different configurations, which is
wrong in some cases.

You can observe this by running:

  ninja -nv check-all | grep debuginfo-tests

And seeing that it passes clang/test and clang/test/debuginfo-tests
to lit, which causes it to run debuginfo-tests twice.  The fix is
going to involve either:

  a) figuring out that we're running in this "deprecated" configuration,
     and then deleting the clang/test/debuginfo-tests path, which should
     cause it to behave identically to before, or:
  b) make lit smart enough that it doesn't descend into a sub-suite if
     that sub-suite already has a lit.cfg file.

llvm-svn: 318486

This was reverted due to some failures on specific darwin buildbots,
the issue being that the new lit configuration was not setting the
SDKROOT environment variable.  We've tested a fix locally and confirmed
that it works, so this patch resubmits everything with the fix
applied.

llvm-svn: 318435

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

This reverts the aforementioned patch and 2 subsequent follow-ups,
as some buildbots are still failing 2 tests because of it.
Investigation is ongoing into the cause of the failures.

llvm-svn: 318112

Previously, debuginfo-tests was expected to be checked out into
clang/test and then the tests would automatically run as part of
check-clang.  This is not a standard workflow for handling
external projects, and it brings with it some serious drawbacks
such as the inability to depend on things other than clang, which
we will need going forward.

The goal of this patch is to migrate towards a more standard
workflow.  To ease the transition for build bot maintainers,
this patch tries not to break the existing workflow, but instead
simply deprecate it to give maintainers a chance to update
the build infrastructure.

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

llvm-svn: 317925

Move the srpm, ocaml_make_directory, llvm_vcsrevision_h, and llvm-headers projects into the Misc folder on IDEs like Visual Studio rather than leave them in the root directory. NFC.

llvm-svn: 317416

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