Summary:
This patch adds a new internal variable
LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution
components that are part of runtime projects, and thus should be exposed
from runtime configuraitons up into the top-level CMake configurations.
This is required for allowing runtime components to be included in
LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and
install targets exist for every component specified for the
distribution.
Without this patch runtimes and builtins can only be included in
distributions in whole, not by component.
Reviewers: phosek
Reviewed By: phosek
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46705
llvm-svn: 332631
This behavior has been the default for a long time, so the default value is On, however this can make it difficult to debug sanitizer failures, so we should have an option to turn it off.
llvm-svn: 332628
It used to symlink dsymutil to llvm-dsymutil, but after r327790 llvm's dsymutil
binary is now called dsymutil without prefix.
r327792 then reversed the direction of the symlink if
LLVM_INSTALL_CCTOOLS_SYMLINKS was set, but that looks like a buildfix and not
like something anyone should need.
https://reviews.llvm.org/D45966
llvm-svn: 330727
These should exist in all toolchains LLVM supports nowadays.
Enables making DataTypes.h a regular header instead of a .h.cmake file and
allows deleting a bunch of cmake goop (which should also speed up cmake
configure time a bit).
All the code this removes is 9+ years old.
https://reviews.llvm.org/D45155
llvm-svn: 328970
Compiler.h is used by Demangle (which Support depends on) - so sink it
into Demangle to avoid a circular dependency
DataTypes.h is used by llvm-c (which Support depends on) - so sink it
into llvm-c.
DataTypes.h could probably be fixed the other way - making llvm-c depend
on Support instead of Support depending on llvm-c - if anyone feels
that's the better option, happy to work with them on that.
I /think/ this'll address the layering issues that previous attempts to
commit this have triggered in the Modules buildbot, but I haven't been
able to reproduce that build so can't say for sure. If anyone's having
trouble with this - it might be worth taking a look to see if there's a
quick fix/something small I missed rather than revert, but no worries.
llvm-svn: 328123
Support depends on llvm-c (a few typedefs, macros, etc - Types.h,
Disassembler.h, and TargetMachine.h.
This could be done the other way - those macros/typedefs/etc could be
moved into Support and used from llvm-c instead. If someone feels that's
a better direction to go, happy to discuss it/try it out/etc.
llvm-svn: 328065
Add a `LLVM_INSTALL_CCTOOLS_SYMLINKS` to mirror
`LLVM_INSTALL_BINUTILS_SYMLINKS`. For now, this allows us to create
symlinks for `dsymutil` to `llvm-dsymutil`. This option is off by
default, but the user can enable it.
llvm-svn: 326381
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
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
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
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
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:
*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
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
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
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
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
By default, CMake uses a 32-bit toolchain, even when on a 64-bit platform targeting a 64-bit build. However, due to the size of the binaries involved, this can cause linker instabilities (such as the linker running out of memory). Guide people to the correct solution to get CMake to use the native toolchain.
llvm-svn: 303912
Summary:
When apps or other libraries link against a library with symbol
versions, the version string is recorded in the import table, and used
at runtime to resolve the symbol back to a library that provides that
version (vaguely like how two-level namespaces work in Mach-O). ld's
--default-symver flag tags every exported symbol with a symbol version
string equal to the library's soname. Using --default-symver means
multiple versions of libLLVM can coexist within the same process, at
least to the extent that they don't try to pass data between each
other's llvms.
As an example, imagine a language like Rust using llvm for CPU codegen,
binding to OpenGL, with Mesa as the OpenGL implementation using llvm for
R600 codegen. With --default-symver Rust and Mesa will resolve their
llvm usage to the version each was linked against, which need not match.
(Other ELF platforms like BSD and Solaris might have similar semantics,
I've not checked.)
This is based on an autoconf version of this patch by Adam Jackson.
This new option can be used to add --default-symver to the linker flags
for libLLVM.so.
Reviewers: beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30997
llvm-svn: 302026
Summary:
VersionPrinter by default outputs information about the Host CPU
and Default target. Printing this information requires linking in
a large amount of data, such as supported target triples as C
strings, which in turn bloats the binary size.
Enable a new CMake option LLVM_VERSION_PRINTER_SHOW_HOST_TARGET_INFO
which controls printing of the host and target info. This allows
the target triple names to be dead-code stripped. This is a nice
win for LLVM clients that wish to minimize their binary size, such
as graphics drivers.
By default this is ON, so there is no change in the default behavior.
Clients who wish to suppress this printing can do so by setting this
option to off via CMake.
A test app on Linux that uses ParseCommandLineOptions() shows a binary
size reduction of 23KB (from 149K to 126K) for a Release build, and 24KB
(from 135K to 111K) in a MinSizeRel build.
Reviewers: klimek, beanz, bogner, chandlerc, compnerd
Reviewed By: compnerd
Patch by pammon (Peter Ammon) !
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30904
llvm-svn: 300630
This could be used to either disable the runtimes build altogether
or avoid building them but still generate the build targets.
Differential Revision: https://reviews.llvm.org/D31060
llvm-svn: 298653
When a python script is run, by default it creates the bytecode file if the directory is writable, and this ‘pollutes’ source folders.
From python's help:
-B Don’t write .py[co] files on import. See also PYTHONDONTWRITEBYTECODE.
Patch by Pere Mato (D30604)!
llvm-svn: 298603
CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided
for host compiler that builds llvm components. A function
add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep
track of these definitions and was intended to be a replacement for CMake
command add_definitions. Actually in many cases add_definitions is still
used and the content of LLVM_DEFINITIONS is not actual now. On the other
hand the current version of CMake allows getting set of definitions in a
more convenient way. This fix implements evaluation of the variable by
reading corresponding cmake property.
Differential Revision: https://reviews.llvm.org/D31125
llvm-svn: 298336
This is a follow-up to my change in r295090, which added support for
disabling these checks selectively based on setting the preprocessor
macro without relying on the Cmake setting. Swift has moved over to use
that approach, so we can clean up here and remove the Cmake setting.
https://reviews.llvm.org/D30578
llvm-svn: 297109
Summary:
'make srpm' or 'ninja srpm' will tar up the current source code and then
build a source RPM package.
By default it will use the llvm.spec file to generate the source RPM,
but you can specify your own custom spec file with the
LLVM_SRPM_USER_BINARY_SPECFILE option. CMake will perform variable
substitution on your custom specfile, so you can reference CMake
variables in it. For example:
Version: @LLVM_RPM_SPEC_VERSION@
Note that everything in the source directory will be included in the
tarball so if you have a clang check out in tools/clang, then all
the clang source will end up in the tarball to. It is recommended
to only use this build target with a clean source tree.
Reviewers: beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30093
llvm-svn: 297007
To help assist in debugging ISEL or to prioritize GlobalISel backend
work, this patch adds two more tables to <Target>GenISelDAGISel.inc -
one which contains the patterns that are used during selection and the
other containing include source location of the patterns
Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV
llvm-svn: 295081
Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them.
llvm-svn: 294334
In order to make sure that LLVM continues to work on machines that do not have the Universal CRT yet,
we'll need to ship a copy of UCRT in the Windows installation package. Fortunately, CMake 3.6+ already
supports app-local deployment of UCRT dlls, we just need to turn this on.
Differential Revision: https://reviews.llvm.org/D29146
llvm-svn: 293373
Now, GlobalISel will be built by default. To turn that off, one has to
use -DLLVM_BUILD_GLOBAL_ISEL=OFF on the cmake command line.
<rdar://problem/30004433>
llvm-svn: 293232
It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool.
This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories.
This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR.
llvm-svn: 288770
Summary:
We recently introduced a feature that enforce at link-time that the
LLVM headers used by a clients are matching the ABI setting of the
LLVM library linked to.
However for clients that are using only headers from ADT and promise
they won't call into LLVM, this is forcing to link libSupport. This
new flag is intended to provide a way to configure LLVM with this
promise for such client.
Reviewers: bob.wilson, compnerd
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27432
llvm-svn: 288754
Building compiler-rt on Darwin produces dozens of meaningless warnings about object files having no symbols during static archive creation. This is very intentional as compiler-rt uses #ifdefs to conditionally compile platform-specific code, and we even have a .cpp source file that only contains static asserts to make sure the environment is configured right. On Linux, this situation is fine and no warning is produced. This patch adds a libtool version detection and if it's new enough, we'll use the -no_warning_for_no_symbols flag that suppresses this warning. Build logs should be much cleaner now!
Differential Revision: https://reviews.llvm.org/D27119
llvm-svn: 288640
The macro LLVM_ENABLE_ABI_BREAKING_CHECKS is moved to a new header
abi-breaking.h, from llvm-config.h. Only headers that are using the
macro are including this new header.
LLVM will define a symbol, either EnableABIBreakingChecks or
DisableABIBreakingChecks depending on the configuration setting for
LLVM_ABI_BREAKING_CHECKS.
The abi-breaking.h header will add weak references to these symbols in
every clients that includes this header. This should ensure that
a mismatch triggers a link failure (or a load time failure for DSO).
On MSVC, the pragma "detect_mismatch" is used instead.
Differential Revision: https://reviews.llvm.org/D26876
llvm-svn: 288082
At the moment optimized tablegen is generated by LLVM_USE_HOST_TOOLS variable that is not set for Visual Sudio since LLVM_ENABLE_ASSERTIONS depends on CMAKE_BUILD_TYPE value that is not equal to "DEBUG" in case of Visual Studio soltion generation.
Modified to do not depend on LLVM_ENABLE_ASSERTIONS value in VS and Xcode cases
Reviewers: beanz
Subscribers: RKSimon, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27135
llvm-svn: 288042
Summary: This should provide the function similar to `--disable-libedit` with the autotools build system, which seems to be missing from the commit (r200595) that adds this.
Reviewers: pcc, beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26550
llvm-svn: 287293
Summary:
The motivation for this is to enable correct detection of dlopen() on Android.
Android does not provide a static version of libdl, so if we add the -static flag
after performing the check, it will succeed even though subsequent link steps
will fail. With this change we correctly detect the absence of libdl in a
LLVM_BUILD_STATIC build on Android.
The link itself still does not succeed because the code does not check the result
of this check properly, but I plan to fix that in a separate change.
Reviewers: beanz
Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits
Differential Revision: https://reviews.llvm.org/D26463
llvm-svn: 287220
This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen.
Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency.
llvm-svn: 287207
Summary:
This allows to have clang and llvm and the other subprojects
side-by-side instead of nested. This can be used with the monorepo or
multiple repos.
It will help having a single set of sources checked out but allows to
have a build directory with llvm and another one with llvm+clang.
Basically it abstracts LLVM_EXTERNAL_xxxx_SOURCE_DIR making it more
convenient by adopting a convention.
Reviewers: bogner, beanz, jlebar
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26365
llvm-svn: 286162
Summary:
Some changes are made to cmake, especially the addition of a new
LLVM_ENABLE_PROJECTS option that makes the build system aware of
the monorepo directory structure.
Also a new script is added in llvm/utils/git-svn/. When present in
the $PATH, it enables a `git llvm` command. It is providing at this
point only the ability to push from the git monorepo: `git llvm push`.
It is intended to evolves with more features, for instance I plan on
features like `git llvm show r284955` to help working with sequential
revision numbers.
The push feature is taken from Justin Lebar's script available here:
https://github.com/jlebar/llvm-repo-tools/
Reviewers: jlebar
Subscribers: mgorny, modocache, llvm-commits
Differential Revision: https://reviews.llvm.org/D26334
llvm-svn: 286123
At least with cmake 3.6.1, the default build type setting was having no
effect; the generated CMakeCache.txt still had an empty CMAKE_BUILD_TYPE.
Force the variable to be set to achieve the desired behavior.
Differential Revision: https://reviews.llvm.org/D26200
llvm-svn: 285789
This patch was produced in conjunction with Michał Górny. It should resolve the issues that were trying to be solved by D25304.
This moves rpath handling into `llvm_add_library` and `add_llvm_executable` so that it is available to all projects using AddLLVM whether built in-tree or out-of-tree.
llvm-svn: 285714
This contains just enough for lib/Target/RISCV to compile. Notably a basic
RISCVTargetMachine and RISCVTargetInfo. At this point you can attempt llc
-march=riscv32 myinput.ll and will find it fails due to the lack of
MCAsmInfo.
See http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html for
further discussion
Differential Revision: https://reviews.llvm.org/D23560
llvm-svn: 285712
The installhdrs target was inconsistently named and would behave
differently depending on whether or not you ran a build first. This
renames it to install-llvm-headers to match other target names and
adds a dependency on intrinsics_gen so that it will always install the
same set of things.
llvm-svn: 285035
Declare the LLVM_CMAKE_PATH to the source directory location of CMake
files, in order to make it possible to easily use them in subprojects.
Such a variable is already declared in most of LLVM projects
(and inconsistently mixed with direct source tree references), including
Clang, LLDB, compiler-rt, libcxx... Declaring it inside main LLVM tree
makes it possible to avoid having to declare fallback values or use
conditionals in those projects.
It should be noted that in some of the subprojects LLVM_CMAKE_PATH is
used to reference generated LLVMConfig.cmake file. However, these
references are conditional to stand-alone builds and explicitly
including this file is unnecessary in combined builds.
Differential Revision: https://reviews.llvm.org/D25724
llvm-svn: 284581
Support overriding the Doxygen & OCamldoc install directories,
and provide a more FHS-compliant defaults for both of them. This extends
r282240 that added this override for Sphinx-built documentation.
LLVM_INSTALL_DOXYGEN_HTML_DIR and LLVM_INSTALL_OCAMLDOC_HTML_DIR are
added, to control the location where Doxygen-generated and
OCamldoc-generated HTML docs are installed appropriately. They both
specify CMake-style install paths, and therefore can either by relative
to the install prefix or absolute.
The new defaults are subdirectories of share/doc/llvm, and replace
the previous directories of 'docs/html' and 'docs/ocaml/html' that
resulted in creating invalid '/usr/docs' that furthermore lacked proper
namespacing for the LLVM package. The new defaults are consistent with
the ones used for Sphinx HTML documentation, differing only in the last
component. Since the 'html' subdirectory is already used for Sphinx
docs, the 'doxygen-html' and 'ocaml-html' directories are used instead.
Differential Revision: https://reviews.llvm.org/D24935
llvm-svn: 282536
Summary:
The previous output was confusing as it would output "Taget triple:
x86_64-unknown-linux-gnu" even when LLVM_HOST_TRIPLE or
LLVM_DEFAULT_TARGET_TRIPLE were set on the CMake command line
Patch by: Alex Richardson!
Reviewers: beanz
Subscribers: Eugene.Zelenko
Differential Revision: https://reviews.llvm.org/D17067
llvm-svn: 282516
My previous attempt at this connected the sub-project check targets to the test-depends target instead of to the check-all target. That resulted in the tests running multiple times on bots that built "test-depends" and "check-all" in separate build invocations.
llvm-svn: 280392
The Xcode and Visual Studio generators always log "-- No build type selected, default to Debug". This is because CMake doesn't initialize "CMAKE_CONFIGURATION_TYPES" until the generator's EnableLanguage call gets hit.
The first place EnableLanguage gets hit in our configuration is in the project() call. Since CMAKE_BUILD_TYPE isn't used until after we call project() it is safe to just move this check down a bit.
llvm-svn: 279110
This patch has the following changes
The CMake variable LLVM_CCACHE_BUILD is set to OFF by default.
Set this to ON for a ccache enabled build
CCACHE_CPP2 is required to compile the source file directly instead
of compiling the preprocessed file. This will help WERROR is turned ON
for a host clang compiler
The below two options makes more sense in the context of a buildbot
CCACHE_HASHDIR is required to maintain the separate cached data across
builders. This will also help the debuggers to point to the correct source
location
CCACHE_SIZE is important in the perspective of buildbot to increase the
limit on the amount of data to hold in cache for faster compilation
CCACHE_DIR is used to save the cached data to a specific directory.
llvm-svn: 277389
OS X 10.11 has a feature named System Integrity Protection. The goal of the feature is to make system binaries immutable (even as root). One part of this is that protected binaries do not receive DYLD_* environment variables because the kernel scrubs them before process launch.
This causes problems for LTO bootstrap builds on Darwin that try to use the just-built libLTO with the host ar, ranlib, or libtool.
This patch addresses two problems.
(1) The tools themselves aren't protected binaries but the shim tools installed at / are, so we need to call xcrun -find to find libtool instead of using the one CMake finds.
(2) Some build tools (ninja and make) use /bin/sh to invoke their subprocesses. Since /bin/sh is a system binary, the kernel scrubs the DYLD envars from their environment. To work around this we need to set the environment variables as part of the archiver commands, so the envars are set by the shell process instead of on the shell process.
llvm-svn: 276710
It's been pointed out that arbitrarily spraying raw profiles into a
build directory is insane. Doing this wastes a tremendous amount of
space and is also very lossy, since the test harness tends to wipe away
temporary sub-directories (which usually contain relevant profile data).
The new default is a `profiles` directory inside of the build dir.
llvm-svn: 276504
This does not change anything by default since LLVM_INCLUDE_UTILS is already set
to TRUE by default. In addition, since LLVM_INCLUDE_TESTS => LLVM_INCLUDE_UTILS,
the only way that this can cause changes is in the case where LLVM_INCLUDE_UTILS
is set to TRUE, but LLVM_INCLUDE_TESTS is FALSE. In that case, building gtest is
not a huge cost.
The reason to do this is that without this change, one can not turn off
LLVM_INCLUDE_TESTS in downstream projects that also use gtest for unittests. It
also just in general makes more sense since LLVM_INCLUDE_UTILS gates FileCheck
and other utilities that are along the lines of gtest.
Additionally from talking with chandlerc, this was not done for any specific
reason, so there is no reason not to do it and lots of benefit to doing it.
llvm-svn: 276342
Previously LLVM_BUILD_GLOBAL_ISEL was a boolean variable and although,
this is strictly identical to an option, it did not convey the
information that the user may set it. Options are here for that.
llvm-svn: 276306
This option is the equivalent option to LLVM_BUILD_TOOLS but for executables
created via add_llvm_utility.
This is a useful tool for improving compile time in situations where LLVM is
used as a library and no testing tools are needed.
It follows the exact same implemention model as LLVM_BUILD_TOOLS.
Since the option is by default set to on, no behavior is changed unless one sets
it from the command line to be false.
llvm-svn: 275007
When compiling with modules, header A and B can be in the same module M.
B depends on intrinsics_gen and A doesn't. Compiling a source file #include-ing
header A, we implicitly request module M to be built. It puts header A and B in
the same TU and tries to build them. Since B depends on intrinsics_gen (which
might not be built yet) we run into build failures.
This should fix our modules buildbot.
Patch reviewed by Chris Bieneman.
llvm-svn: 274270
On Darwin it is currently impossible to build LLVM with modules
because the Darwin system module map is not compatible with
-fmodules-local-submodule-visibility at this point in time. This
patch makes the flag optional and off by default on Darwin so it
becomes possible to build LLVM with modules again.
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274196
Summary:
There are a few LLVM projects that produce runtime libraries. Ideally
runtime libraries should be built differently than other projects,
specifically they should be built using the just-built toolchain.
There is support for building compiler-rt in this way from the clang
build. Moving this logic into the LLVM build is interesting because it
provides a simpler way to extend the just-built toolchain to include
LLD and the LLVM object file tools.
Once this functionality is better fleshed out and tested we’ll want to
encapsulate it in a module that can be used for clang standalone
builds, and we’ll want to make it the default way to build compiler-rt.
With this patch applied there is no immediate change in the build.
Moving compiler-rt out from llvm/projects into llvm/runtimes enables
the functionality.
This code has a few improvements over the method provided by
LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is
always invoked, so changes to compiler-rt source files will get built
properly, so this patch can be used for iterative development with
just-built tools.
This first patch only works with compiler-rt. Support for other
runtime projects will be coming in follow-up patches.
Reviewers: chandlerc, bogner
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D20992
llvm-svn: 273620
This patch adds a new option LLVM_TOOLS_INSTALL_DIR which allows customizing the location executables and symlinks get installed to. This adds the functionality provided by autoconf's --bindir flag.
This patch is based on patches from and collaboration with Tony Kelman, and replaces http://reviews.llvm.org/D20934.
llvm-svn: 272200
Summary:
As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS.
The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled.
With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic.
See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html
Reviewers: bogner, silvas, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19892
llvm-svn: 268670
This backend was supposed to generate C++ code which will re-construct
the LLVM IR passed as input. This seems to me to have very marginal
usefulness in the first place.
However, the code has never been updated to use IRBuilder, which makes
its current value negative -- people who look at the output may be
steered to use the *wrong* C++ APIs to construct IR.
Furthermore, it's generated code that doesn't compile since at least
2013.
Differential Revision: http://reviews.llvm.org/D19942
llvm-svn: 268631
Summary:
Before this change certain Polly variables have been used both as user-facing
CACHED cmake variables as well as uncached internal variables. Even though
this seems to have worked OK in practice, the behavior only worked due to
one variable shadowing the other. This behavior has been found confusing.
To make the use of cmake variables more clear we now prefix the cached, user
facing variables with LLVM_ as it is common habit for LLVM options and also
moved the _POLLY_ term to the beginning to ensure related options are sorted
after each other. The variables that control the behavior of LLVM/Polly are then
set by forwarding the values set in the user facing option variables.
As a result, Polly is now enabled with LLVM_POLLY_BUILD instead of BUILD_POLLY
and the linking behavior of Polly is controlled with LLVM_POLLY_LINK_INTO_TOOLS
instead of LINK_POLLY_INTO_TOOLS.
Reviewers: bogner, Meinersbur
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D19907
llvm-svn: 268537
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
llvm-svn: 268050
This is the second try. This time we disable this feature if no Polly checkout
is available. For this to work we need to check if tools/polly is present
early enough that our decision is known before cmake generates Config/config.h.
With Polly checked into LLVM it was since a long time possible to compile
clang/opt/bugpoint with Polly support directly linked in, instead of only
providing Polly as a separate loadable module. This commit switches the
default from providing Polly as a module to linking Polly into tools, such
that it becomes unnecessary to load the Polly module when playing with Polly.
Such configuration has shown a lot more convenient for day-to-day Polly use.
This change does not impact the default behavior of any tool, if Polly is not
explicitly enabled when calling clang/opt/bugpoint Polly does not affect
compilation.
This change also does not impact normal LLVM/clang checkouts that do not
contain Polly.
Reviewers: jdoerfert, Meinersbur
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D19711
llvm-svn: 268048
With Polly checked into LLVM it was since a long time possible to compile
clang/opt/bugpoint with Polly support directly linked in, instead of only
providing Polly as a separate loadable module. This commit switches the
default from providing Polly as a module to linking Polly into tools, such
that it becomes unnecessary to load the Polly module when playing with Polly.
Such configuration has shown a lot more convenient for day-to-day Polly use.
This change does not impact the default behavior of any tool, if Polly is not
explicitly enabled when calling clang/opt/bugpoint Polly does not affect
compilation.
This change also does not impact normal LLVM/clang checkouts that do not
contain Polly.
Reviewers: jdoerfert, Meinersbur, sebpop, etherzhhb, zinob, hiraditya
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D19711
llvm-svn: 268033
Summary: Using libtool instead of ar and ranlib on Darwin shaves a minute off my clang build. This is because on Darwin libtool is optimized to give hints to the kernel about filesystem interactions that allow it to be faster.
Reviewers: bogner, pete
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19611
llvm-svn: 267930
If anybody is actually using this, it probably doesn't do what they
think it does. This actually causes the dylib to *export* a
__cxa_atexit symbol, so anything that links it probably loses their
exit time destructors as well as disabling LLVM's.
This just removes the option entirely. If somebody does need this
behaviour we should figure out a more principled way to do it.
This is effectively a revert of r223805.
llvm-svn: 263498
This allows a user to specify "Native" as a target when configuring LLVM. Native will resolve to the LLVM_NATIVE_ARCH, which is the target that supports code generation for the host.
llvm-svn: 262070
The idea here is to provide a customizable install target that only depends on building the things you actually want to install. It relies on each component being installed having an auto-generated install-${component}, which in turn depends only on the target being installed.
This is fundamentally a workaround for the fact that CMake generates build files which have their "install" target depend on the "all" target. This results in "ninja install" building a bunch of unneeded things.
llvm-svn: 261681
This patch adds the necessary plumbing to cmake to build the sources related to
GlobalISel.
To build the sources related to GlobalISel, we need to add -DBUILD_GLOBAL_ISEL=ON.
By default, this is OFF, thus GlobalISel sources will not impact people that do
not explicitly opt-in.
Differential Revision: http://reviews.llvm.org/D15983
llvm-svn: 258344
This reverts r257221.
This caused several build bot failures
* It looks like some of the tests don't work correctly under Windows
* It looks like the lit per test timeout tests fail
So I'm reverting for now. Once the above failures are fixed running
lit's tests can be enabled again.
llvm-svn: 257268
directy with ``make check-lit`` and are run as part of
``make check-all``.
In principle we should run lit's testsuite before testing LLVM using lit
so that any problems with lit get discovered before testing LLVM so we
can bail out early. However this implementation (``check-all`` runs all
tests together) seemed simpler and will still report failing lit tests.
Note that the tests and the configured ``lit.site.cfg`` have to be
copied into the build directory to avoid polluting the source tree.
llvm-svn: 257221
This generates a compile_commands.json file, which tells tools like
YouCompleteMe and clang_complete exactly how to build each source file.
Patch by Justin Lebar!
llvm-svn: 255789
Summary: This adds support for generating dSYM files and stripping debug info from executables and dylibs. It also supports passing -object_path_lto to the linker to generate dSYMs for LTO builds.
Reviewers: bogner, friss
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15133
llvm-svn: 254627
Summary:
This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out.
The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt.
This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx.
Reviewers: samsonov, jroelofs, rengolin, jmolloy
Subscribers: jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D14513
llvm-svn: 252747
Summary:
We've had a lot of discussion in the past about the meaningful and useful default behaviors for the llvm-shlib tool. The original implementation was heavily geared toward Apple's use, and I think that was wrong. This patch seeks to correct that.
I've removed the LLVM_DYLIB_EXPORT_ALL variable and made libLLVM export everything by default.
I've also added a new target that is only built on Darwin for libLLVM-C as a library that re-exports the LLVM-C API. This library is not built on Linux because ELF doesn't support re-export libraries in the same way MachO does.
Reviewers: chapuni, resistor, bogner, axw
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13842
llvm-svn: 251411
This is because if you set one of the variables to 0, if(NOT ...) is true, which isn't what you actually want. Should have thought that through better the first time.
llvm-svn: 250841
CMake's set command overwrites existing values. Package maintainers may want or need to set the version variables manually, so we need to only set them if they are not already defined. Note I use the "if(NOT DEFINED ...)" syntax deliberately in the last case because empty string is a valid value for the suffx, but not the other variables.
llvm-svn: 250333
CMake 3.0 introduced the VERSION option for the project() command. If you don't specify the VERSION in the function it will clear out variables matching ${PROJECT_NAME}_VERSION_${MAJOR|MINOR|PATCH|TWEAK}.
This makes overriding LLVM_VERSION_* not work properly with newer versions of CMake. To make this work properly we need to:
(1) Optionally set the policy to NEW
(2) Move default versions and setting PACKAGE_VERSION to before the call to project()
(3) If the policy is set, pass the VERSION and LANGUAGES options in the new format
This change should have no behavioral change for CMake versions before 3.0, and it makes the behavior of later versions match the earlier versions.
llvm-svn: 250275
CMake.
The Go bindings tests in an unoptimized build take over 30 seconds for
me, making it the slowest test in 'check-llvm' by a factor of two.
I've only rigged this up fully to the CMake build. If someone is
interested in rigging it up to the autoconf build, they're welcome to do
so.
llvm-svn: 247243
Summary:
Cross-compilation uses recursive cmake invocations to build native host
tools. These recursive invocations only forward a fixed set of
variables/options, since the native environment is generally the default.
This change adds -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE to the recursive
cmake invocations, so that cmake files can distinguish these recursive
invocations from top-level ones, which can explain why expected options
are unset.
LLILC will use this to avoid trying to generate its build rules in the
crosscompile native host target (where it is not needed), which would fail
if attempted because LLILC requires a cmake variable passed on the command
line, which is not forwarded in the recursive invocation.
Reviewers: rnk, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12679
llvm-svn: 247151
Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.
We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.
add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.
llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.
One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.
Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
- link all tools and shared libraries to libLLVM if
LLVM_LINK_LLVM_DYLIB is set
- some way of explicitly *not* doing so for utilities
and libLLVM itself
Suggestions for improvement here are particularly welcome.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12590
llvm-svn: 246918
Summary:
Three closely related changes, to have a mode in which we link all
executables and shared libraries against libLLVM.
1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link
executables and shared libraries against libLLVM. For this to work, it
is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL.
It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but
we also default to OFF in this mode, or tools tend to misbehave (e.g.
stdout may not flush on exit when output is buffered.)
llvm-config and Tablegen do not use libLLVM, as they are dependencies of
libLLVM.
2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib".
Depending on which one is passed (default is component-libs), we link
with the individual libraries or libLLVM respectively. We pass in dylib
when LLVM_LINK_LLVM_DYLIB is ON.
3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to
actually export all. Don't strip leading underscore from symbols on Linux,
and make sure we get all exported symbols and weak-with-default symbols
("W" in nm output). Without these changes, passes won't load because
the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not
found.
Testing:
- Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb.
- Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've
never had much success with LLDB tests, and llgoi is currently broken
so check-llgo fails for an unrelated reason.
- Ran "lldb" to ensure it loads.
Reviewers: chandlerc, beanz, pcc, rnk
Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits
Differential Revision: http://reviews.llvm.org/D12488
llvm-svn: 246527
Only disable the progress bar when we're generating VS project files,
like we do for XCode. This makes lit use the simple, non-curses progress
bar that looks like this with:
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 5.87s
llvm-svn: 244674
Apparently if you make a typo in the argument to CMAKE_BUILD_TYPE,
cmake silently accepts this but doesn't apply any particular build
type to your build. This means you get a build that doesn't really
make any sense - it's sort of a debug build with asserts disabled.
Error out instead.
llvm-svn: 244406
This allows asm files and Cxx files to be compiled with different flags
rather than treating them identically. LLVM itself has no asm files
other than tests, but this setting is inherited by the compiler-rt
project (unless compiled standalone), which does have asm files.
Differential Revision: http://reviews.llvm.org/D10707
llvm-svn: 243419
Enabling Ninja Job Pools needs to be dependent on the CMAKE_MAKE_PROGRAM not the CMAKE_GENERATOR. There are generators (like "Sublime Text 2 - Ninja") that also generate ninja build files. Basing of the CMAKE_MAKE_PROGRAM is the best future-proof way to handle this.
llvm-svn: 239076
The current check never passes, because CMAKE_MAKE_PROGRAM, at least on Linux,
includes the full path to the "ninja" binary; this effectively disables
compile/link jobs pools.
Use CMAKE_GENERATOR STREQUAL "Ninja" as a more reliable check.
llvm-svn: 239069
Summary: I've gotten feedback from users on CMake 2.8 that the compile and link pool options were not working. This is expected so I'm adding a warning so we can report invalid configurations to users.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10193
llvm-svn: 239044
Added a new boolean CMake flag, LLVM_INSTALL_UTILS. When set,
the 'install' target will include in the bin directory the
utils binaries - e.g. FileCheck. This mirrors the autoconfig
behavior.
Test Plan:
Locally verified that utils binaries are copied when flag is set,
and not copied when flag is not set.
Reviewers: jfb, dschuff, beanz
Reviewed By: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8587
Patch by Mircea Trofin
llvm-svn: 233385
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are
predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`.
`LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with
`LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake /
autoconf build system.
Reviewers: chandlerc, dexonsmith, rnk, zturner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8351
llvm-svn: 233310
In r233009 we gained specific check-llvm-* build targets for invoking
specific parts of the test suite, but they were copying the
dependencies for check-all, rather than just listing the dependencies
for check-llvm.
This moves the creation of these targets next to the check-llvm
target, and uses that target's configuration rather than the check-all
config.
llvm-svn: 233174
Summary:
This change makes CMake scan for lit suites and generate a target for each lit test suite. The targets follow the format check-<project>-<suite path>.
For example:
check-llvm-unit - Runs the LLVM unit tests
check-llvm-codegen-arm - Runs the ARM codeine tests
Note: These targets are not generated during multi-configuration generators (i.e. Xcode and Visual Studio) because target clutter impacts UI usability.
* Also fixed a minor issue that Duncan pointed out to me I was passing the suite to lit twice
Reviewers: chandlerc
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D8380
llvm-svn: 233009
Summary:
This change makes CMake scan for lit suites and generate a target for each lit test suite. The targets follow the format check-<project>-<suite path>.
For example:
check-llvm-unit - Runs the LLVM unit tests
check-llvm-codegen-arm - Runs the ARM codeine tests
Note: These targets are not generated during multi-configuration generators (i.e. Xcode and Visual Studio) because target clutter impacts UI usability.
Reviewers: chandlerc
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D8380
llvm-svn: 232671
The MSVC linker won't produce a .lib file for an executable that doesn't
export anything, and LLVM doesn't maintain dllexport annotations or .def
files listing all C++ symbols. It also doesn't support exporting all
symbols, like binutils ld.
CMake 3.2 changed the Ninja generator to list both the .exe and .lib
files as outputs of executable build targets. Ninja would always re-link
executables with ENABLE_EXPORTS because the .lib output file was not
present, and therefore the target was out of date.
llvm-svn: 232662
Summary: This change leverages the cross-compiling functionality in the build system to build a release tablegen executable for use during the build.
Reviewers: resistor, rnk
Reviewed By: rnk
Subscribers: rnk, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D7349
llvm-svn: 231842
libc++. This lets me almost self-host on Linux with libc++ and libc++abi
very simply.
Currently, MCJIT and OrcJIT are failing due to uncaught exceptions, and
the Go binding tests are failing to build due to not linking in the
correct C++ standard library.
llvm-svn: 231560
When you use generator expressions in a library sources list,
and then later access the SOURCES property, the OLD behavior
(CMake 3.0 and earlier) would not include these expressions in
the SOURCES property. The NEW behavior (starting in CMake 3.1)
is that they do include the generator expressions in the SOURCES
property.
Differential Revision: http://reviews.llvm.org/D7870
Reviewed By: Chris Bieneman
llvm-svn: 230396
This reverts commit r230062.
Debian stable (wheezy) ships still with cmake 2.8.9.
The commit broke my LLVM/Polly buildbot, to my knowledge our only Linux+cmake
buildbot.
llvm-svn: 230343
Summary: Turns out if you don't set CMAKE_BUILD_TYPE the default is an empty string. This results in some of the behaviors of debug builds, but not all of them. For example ENABLE_ASSERTIONS is false.
Reviewers: rnk
Reviewed By: rnk
Subscribers: chapuni, llvm-commits
Differential Revision: http://reviews.llvm.org/D7360
llvm-svn: 230041
Summary:
* add_llvm_tool and add_llvm_library now add install-${name} targets to install specific components
* added installhdrs target to install just the LLVM headers
* The above changes only apply for single-configuration generators (Ninja, Makefiles...), not for multi-configuration generators (Visual Studio, Xcode...)
Reviewers: pete
Reviewed By: pete
Subscribers: pete, llvm-commits
Differential Revision: http://reviews.llvm.org/D7619
llvm-svn: 229727
If we are building an 64bit installer on Windows we have to adjust the
Program Files path otherwise it uses the wrong Program Files (x86)
directory. Related CMake bug report
http://public.kitware.com/Bug/view.php?id=14211
Patch by Ismail Dönmez!
llvm-svn: 227999
*numerous* places where it was missing in the CMake build. The primary
change here is that the suffix is now actually used for all of the lib
directories in the LLVM project's CMake. The various subprojects still
need similar treatment.
This is the first of a series of commits to try to make LLVM's cmake
effective in a multilib Linux installation. I don't think many people
are seriously using this variable so I'm hoping the fallout will be
minimal. A somewhat unfortunate consequence of the nature of these
commits is that until I land all of them, they will in part make the
brokenness of our multilib support more apparant. At the end, things
should actually work.
llvm-svn: 224919
Summary:
This is desirable for WebKit and other clients of the llvm-shlib because C++ exit time destructors have a tendency to crash when invoked from multi-threaded applications.
Ideally this option will be temporary, because the ideal fix is to just not have exit time destructors.
Reviewers: chapuni, ributzka
Reviewed By: ributzka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6572
llvm-svn: 223805
This change makes use of the new "job pool" capability in cmake 3.0
with ninja generator to allow limiting the number of concurrent jobs
of a certain type.
llvm-svn: 222341
A shared library (unlike a .a), has its dependencies recorded in the library and
we can pass PRIVATE to target_link_libraries.
This patch then removes some bogus dependencies when using
BUILD_SHARED_LIBS=ON. For example, we go from
build lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/AggressiveAntiDepBreaker.cpp.o:
CXX_COMPILER /home/espindola/llvm/llvm/lib/CodeGen/AggressiveAntiDepBreaker.cpp
|| include/llvm/IR/intrinsics_gen lib/libLLVMSupport.so
lib/libLLVMCore.so lib/libLLVMBitReader.so
lib/libLLVMTransformUtils.so lib/libLLVMInstCombine.so
lib/libLLVMScalarOpts.so lib/libLLVMipa.so lib/libLLVMAnalysis.so
lib/libLLVMMCParser.so lib/libLLVMMC.so lib/libLLVMObject.so
lib/libLLVMTarget.so lib/libLLVMProfileData.so
to
build lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/AggressiveAntiDepBreaker.cpp.o:
CXX_COMPILER /home/espindola/llvm/llvm/lib/CodeGen/AggressiveAntiDepBreaker.cpp
|| include/llvm/IR/intrinsics_gen lib/libLLVMSupport.so
lib/libLLVMCore.so lib/libLLVMTransformUtils.so
lib/libLLVMScalarOpts.so lib/libLLVMAnalysis.so lib/libLLVMMC.so
lib/libLLVMTarget.so
In fact, build.ninja goes from 5231028 bytes to 4896759 bytes.
With this, old verisons of bfd ld (2.24 is OK, 2.23 warns) will print a bogus
warning when building with BUILD_SHARED_LIBS.
llvm-svn: 221530
Summary:
This patch adds a new CMake build setting LLVM_BUILD_LLVM_DYLIB, which defaults to OFF. When set to ON, this will generate a shared library containing most of LLVM. The contents of the shared library can be overriden by specifying LLVM_DYLIB_COMPONENTS. LLVM_DYLIB_COMPONENTS can be set to a semi-colon delimited list of any LLVM components that you llvm-config can resolve.
On Windows, unless you are using Cygwin, you must specify an explicit symbol export file using LLVM_EXPORTED_SYMBOL_FILE. On Cygwin and all unix-like platforms if you do not specify LLVM_EXPORTED_SYMBOL_FILE, an export file containing only the LLVM C API will be auto-generated from the list of LLVM components specified in LLVM_DYLIB_COMPONENTS.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, llvm-commits
Differential Revision: http://reviews.llvm.org/D5890
llvm-svn: 220490
The basic idea is similar to the existing cross compilation support. A directory must be configured to build host versions of tablegen tools and llvm-config. This directory can be user provided (and configured), or it can be created during the build. During a build the native build directory will be configured and built to supply the tablegen tools used during the build. A user could also explicitly provide the tablegen executables to run on the CMake command line.
llvm-svn: 217105
The option check was being performed after config.h/llvm-config.h substitution,
generating incorrect macro definitions.
Fixes PR19614.
llvm-svn: 210311
This commit starts with a "git mv ARM64 AArch64" and continues out
from there, renaming the C++ classes, intrinsics, and other
target-local objects for consistency.
"ARM64" test directories are also moved, and tests that began their
life in ARM64 use an arm64 triple, those from AArch64 use an aarch64
triple. Both should be equivalent though.
This finishes the AArch64 merge, and everyone should feel free to
continue committing as normal now.
llvm-svn: 209577
I'm doing this in two phases for a better "git blame" record. This
commit removes the previous AArch64 backend and redirects all
functionality to ARM64. It also deduplicates test-lines and removes
orphaned AArch64 tests.
The next step will be "git mv ARM64 AArch64" and rewire most of the
tests.
Hopefully LLVM is still functional, though it would be even better if
no-one ever had to care because the rename happens straight
afterwards.
llvm-svn: 209576
The option LLVM_ENABLE_SPHINX option enables the "docs-llvm-html",
"docs-llvm-man" targets but does not build them by default. The
following CMake options have been added that control what targets are
made available
SPHINX_OUTPUT_HTML
SPHINX_OUTPUT_MAN
If LLVM_BUILD_DOCS is enabled then the enabled docs-llvm-* targets will
be built by default and if ``make install`` is run then docs-llvm-html
and docs-llvm-man will be installed (tested on Linux only).
The add_sphinx_target function is in its own file so it can be included
by other projects that use Sphinx for their documentation.
Patch by Daniel Liew <daniel.liew@imperial.ac.uk>!
llvm-svn: 206655
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
the first run of the polly buildbot failed, and then it started passing.
This is due to the fact that the buildbot re-builds in an existing directory,
and the first run does not have WITH_POLLY set when it enters tools/.
Thus, cmake ignores the tools/polly dir in the first run, and then because
it reuses the CMakeCache.txt of the previous run, it has the WITH_POLLY set
by the previous run, and so it passes the second time.
llvm-svn: 203615
Chris Bieneman