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

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