After a lot of discussion in this diff the consensus was that it is really hard to guess the users intention with their LLVM build. Instead of trying to guess if Debug or Release is the correct default option we opted for just not specifying CMAKE_BUILD_TYPE a error.
Discussion on discourse here:
https://discourse.llvm.org/t/rfc-select-a-better-linker-by-default-or-warn-about-using-bfd
Reviewed By: hans, mehdi_amini, aaron.ballman, jhenderson, MaskRay, awarzynski
Differential Revision: https://reviews.llvm.org/D124153
Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.
I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.
Differential Revision: https://reviews.llvm.org/D123126
This re-lands 6316129e06 after fixing the condition logic.
The new flag seems to not be working yet on Windows, where the builtin
trap isn't "no return".
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121750
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
Prior to this change, we would make check-all depend on check-runtimes
which is a target that runs tests in the runtimes build. This means that
the runtimes tests are going to run prior to other test suites in
check-all, and if one of them fails, we won't run the other test suites
at all.
To address this issue, we instead collect the list of test suites and
their dependencies from the runtimes subbuild, and include them in
check-all, so a failure of runtimes test suite doesn't prevent other
test suites from being executed.
This addresses https://github.com/llvm/llvm-project/issues/54154.
Differential Revision: https://reviews.llvm.org/D121276
Symbol versioning can prevent unintented install-time conflicts
between different llvm versions. Users may need to override this
for particular products (e.g. Julia), but this requires carrying
a source code patch. This patch moves this ability to a
configuration option. NFC for existing usage.
Differential Revision: https://reviews.llvm.org/D118672
If the user doesn't specify a default target triple, the LLVM CMake usually defaults us into the host triple. This is a problem when building Clang/LLVM on 64-bit AIX (i.e. powerpc64-ibm-aix), as the host toolchain (e.g. ar, ld, nm, dump) all expect the compiler to generate 32-bit objects by default (which both GCC and XL on the platform do) and will hard error if passed a 64-bit object without an explicit option or environment setting. This breaks downstream consumers, such as builds generated with build tools like CMake, which when they invoke clang, etc. without explicit bitmode flags also expect 32-bit mode.
This patch changes the default target selection when the host is powerpc64-ibm-aix to prefer powerpc-ibm-aix to avoid these issues. We don't update the runtimes/CMakeList.txt since the default is less meaningful as we assume runtimes will need to build for both targets anyways.
Differential Revision: https://reviews.llvm.org/D118377
Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.
The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.
Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D117639
The tensorflow AOT compiler can cross-target, but it can't run on (for
example) arm64. We added earlier support where the AOT-ed header and object
would be built on a separate builder and then passed at build time to
a build host where the AOT compiler can't run, but clang can be otherwise
built.
To simplify such scenarios given we now support more than one AOT-able
case (regalloc and inliner), we make the AOT scenario centered on whether
files are generated, case by case (this includes the "passed from a
different builder" scenario).
This means we shouldn't need an 'umbrella' LLVM_HAVE_TF_AOT, in favor of
case by case control. A builder can opt out of an AOT case by passing that case's
model path as `none`. Note that the overrides still take precedence.
This patch controls conditional compilation with case-specific flags,
which can be enabled locally, for the component where those are
available. We still keep an overall flag for some tests.
The 'development/training' mode is unchanged, because there the model is
passed from the command line and interpreted.
Differential Revision: https://reviews.llvm.org/D117752
The bulk of the implementation is common between 'release' mode (==AOT-ed
model) and 'development' mode (for training), the main difference is
that in development mode, we may also log features (for training logs),
inject scoring information (currently after the Virtual Register
Rewriter) and then produce the log file.
This patch also introduces the score injection pass, 'Register
Allocation Pass Scoring', which is trivially just logging the score in
development mode.
Differential Revision: https://reviews.llvm.org/D117147
This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project.
Additionally:
Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables.
---
This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs.
This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt."
(I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.)
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D100810
See the docs in the new function for details.
I think I found every instance of this copy pasted code. Polly could
also use it, but currently does something different, so I will save the
behavior change for a future revision.
We get the shared, non-installed CMake modules following the pattern
established in D116472.
It might be good to have LLD and Flang also use this, but that would be
a functional change and so I leave it as future work.
Reviewed By: beanz, lebedev.ri
Differential Revision: https://reviews.llvm.org/D116521
Add CMake variable LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS to allow
arguments to be passed to the native tool used in CMake --build
invocations for external projects.
Can be used to pass extra arguments for enhanced versions of build
tools, e.g. distributed build options.
Differential Revision: https://reviews.llvm.org/D115815
Although we moved to Github Issues. The bug report message refers to
Bugzilla still. This patch tries to update these URLs.
Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++
Differential Revision: https://reviews.llvm.org/D116351
- Change a stray tab to spaces
- 4 not 2 spaces in second line of `set` like above.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D116510
It’s still possible to build parts of the main llvm build (lld, clang etc) by symlinking them into llvm/tools.
Reviewed By: Ericson2314
Differential Revision: https://reviews.llvm.org/D116472
With a fix for BUILD_SHARED_LIBS.
Original commit message:
When building LLVM static libraries, we should not make symbols more
visible than CMAKE_CXX_VISIBILITY_PRESET, since the goal may be to have
a purely hidden llvm embedded in another library. Instead, we only
define LLVM_EXTERNAL_VISIBILITY for the dynamic library build (when
LLVM_BUILD_LLVM_DYLIB=YES or BUILD_SHARED_LIBS=YES).
Original Review: https://reviews.llvm.org/D113610
Differential Revision: https://reviews.llvm.org/D115825
Pulled the latest (b000672), which adds an option to disable -Werror,
which caused issues previously (see for instance
https://reviews.llvm.org/D112012)
Applied https://github.com/google/benchmark/pull/1305 to unblock, as
this issue is causing downstream buildbot failures.
The only change is in llvm/CMakeLists.txt, where we set
BENCHMARK_ENABLE_WERROR to have the same value as LLVM_ENABLE_WERROR.
This patch also introduces a convenience script to pull benchmark from
upstream.
Differential Revision: https://reviews.llvm.org/D115684
Sets LLVM_ENABLE_CURL to OFF by default to avoid accidental inclusion of libcurl in builds which do not override the default.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D115500
This reverts commit 492de35df4.
I tried to apply John's changes in 8d897ec915 that were expected to
fix his patch but that didn't work unfortunately.
Reverting this again to fix the macOS bots and leave him more time to
investigate the issue.
This reverts commit 797b50d4be.
See the original D99484. @mib who noticed the original problem could not longer
reproduce it, after I tried and also failed. We are threfore hoping it went
away on its own!
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D115544
This reverts commit e7568b68da and relands
c6f7b720ec.
The culprit was: missed that libc also had a dependency on one of the
copies of `google-benchmark`
Also opportunistically fixed indentation from prev. change.
Differential Revision: https://reviews.llvm.org/D112012
under third-party
This change:
- moves the libcxx copy of `google/benchmark` to
`third-party/benchmkark`
- points the 2 uses of the library (libcxx and llvm/utils) to this copy
We picked the licxx copy because it is the most up to date.
Differential Revision: https://reviews.llvm.org/D112012
When cross-compiling LLVM in an environment where there //is// an
objdump binary available but it does not understand the target
platform's object file format, extract_symbols.py fails, because its
initial check for tool availability decides that the existence of
objdump at all is good enough to settle on it as the tool of choice.
In such an environment it's useful to work around this by telling
extract_symbols.py to use llvm-readobj instead. The script itself has
an option for that, but its invocation in AddLLVM.cmake wasn't
providing a mechanism to add extra options passed through for the
cmake command line.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D113557
[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.
Reviewed By: #libc, ldionne, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113186
Default to preferring forward slashes when built for MinGW, as
many usecases, when e.g. Clang is used as a drop-in replacement
for GCC, requires the compiler to output paths with forward slashes.
Not all tests pass yet, if configuring to prefer forward slashes though.
Differential Revision: https://reviews.llvm.org/D112787
This is a new draft of D28234. I previously did the unorthodox thing of
pushing to it when I wasn't the original author, but since this version
- Uses `GNUInstallDirs`, rather than mimics it, as the original author
was hesitant to do but others requested.
- Is much broader, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I am using this patch (and many back-ports) as the basis of
https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS). It
looked like people were generally on board in D28234, but I make note of
this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM
already has some partial support for these sorts of things. For example
`LLVM_LIBDIR_SUFFIX`, or `COMPILER_RT_INSTALL_PATH`. Because it's not
quite clear yet what to do about those, we are holding off on changing
libdirs and `compiler-rt`. for this initial PR.
---
On the advice of @lebedev.ri, I am splitting this up a bit per
subproject, starting with LLVM. To allow it to be more easily reviewed. This and the subsequent patch must be landed together, as this will not build alone. But the rest can be landed on their own.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D100810
This updates the LLVM wide documentation for building LLVM and the runtimes
and adds a CMake warning when folks specify libcxx, libcxxabi or libunwind
in LLVM_ENABLE_PROJECTS, pointing them to the updated instructions for
building the runtimes.
Differential Revision: https://reviews.llvm.org/D112724
The tests that exercise the 'release' mode, where the model is AOT-ed,
check the output has certain properties, to validate that, indeed, a
different policy from the default one was exercised. For determinism, we
can't reliably check that output for an arbitrary learned policy, since
it could be that policy happens to mimic the default one in that
particular case.
This patch adds a requirement that those tests run only when the model
is autogenerated (e.g. on build bots).
Differential Revision: https://reviews.llvm.org/D111747
Due to the way detecting the hard float ABI is currently
handled, clang fails to find the per target dir.
I am working to fix this but in the meantime disable it by
default on Arm Linux.
Tobias Hieta