Summary:
The CMake documentation says that the `DEPENDS` field of
add_custom_target is for files and output of custom commands. Adding a
dependency on a target should be done with `add_dependency`.
Differential Revision: https://reviews.llvm.org/D60879
llvm-svn: 359042
This allows the cross compiled build targets to configure the LLVM tools and sub-projects that are part of the main build.
This is needed for generating native non llvm *-tablegen tools when cross compiling clang in the monorepo build environment.
llvm-svn: 358779
Summary:
Extra flexibility for emitting debug info to external files (remains Darwin only for now).
LLDB needs this functionality to emit a LLDB.framework.dSYM instead of LLDB.dSYM when building the framework, because the latter could conflict with the driver's lldb.dSYM when emitted in the same directory on case-insensitive file systems.
Reviewers: friss, bogner, beanz
Subscribers: mgorny, aprantl, llvm-commits, #lldb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60862
llvm-svn: 358685
Summary:
This code was added in r141266 to make a breaking change to CMake, but
still be compatible with existing cache files. The cache files from
2011 are irrelevant today in 2019.
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60711
llvm-svn: 358482
Summary:
There is a bug in add_tablegen which causes cmake to fail with the following
error message if LLVM_TABLEGEN is set.
CMake Error at cmake/modules/TableGen.cmake:147 (add_dependencies):
The dependency target "LLVM-tablegen-host" of target "CLANG-tablegen-host"
does not exist.
Call Stack (most recent call first):
tools/clang/utils/TableGen/CMakeLists.txt:3 (add_tablegen)
The issue happens because setting LLVM_TABLEGEN causes cmake to skip generating
the LLVM-tablegen-host target. As a result, a non-existent target was added for
CLANG-tablegen-host causing cmake to fail.
In order to fix this issue, this patch adds a guard to check the validity of the
dependency target before adding it as a dependency.
Reviewers: aganea, smeenai
Reviewed By: aganea
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60576
llvm-svn: 358226
Standalone builds of projects other than llvm itself (lldb, libcxx,
etc) include HandleLLVMOptions but not the top level llvm CMakeLists,
so we need to set this variable here to ensure that it always has a
value.
This should fix the build issues some folks have been seeing.
llvm-svn: 357976
Simplify building with particular C++ standards by replacing the
specific "enable standard X" flags with a flag that allows specifying
the standard you want directly.
We preserve compatibility with the existing flags so that anyone with
those flags in existing caches won't break mysteriously.
Differential Revision: https://reviews.llvm.org/D60399
llvm-svn: 357899
Modify the add_header_files_for_glob() function to only add files
that do exist, rather than all matches of the glob. This fixes CMake
error when one of the include directories (which happen to include
/usr/include) contain broken symlinks.
Differential Revision: https://reviews.llvm.org/D59632
llvm-svn: 357701
Instead of duplicating functionality for building native versions of
tblgen and llvm-config, add a function to set up a native tool build.
This will also be used for llvm-nm in a follow-up.
This should be NFC for tblgen, besides the slightly different COMMENT
for the custom command (it'll display the tablegen target name instead
of always saying TableGen). For the native llvm-config, it's a behavior
change in that we'll use llvm_ExternalProject_BuildCmd instead of
constructing the build command manually, always build in Release, and
reference the correct binary path for multi-config generators. I believe
all of these changes to be bug fixes.
Differential Revision: https://reviews.llvm.org/D60024
llvm-svn: 357486
Use $<CONFIG> instead of $<CONFIGURATION>, since the latter has been
deprecated since CMake 3.0, and the former is entirely equivalent.
llvm-svn: 357338
A bunch of macros use the same variable name, and since CMake macros
don't get their own scope, the value persists across macro invocations,
and we can end up exporting targets which shouldn't be exported. Clear
the variable before each use to avoid this.
Converting these macros to functions would also help, since it would
avoid the variable leaking into its parent scope, and that's something I
plan to follow up with. It won't fully address the problem, however,
since functions still inherit variables from their parent scopes, so if
someone in the parent scope just happened to use the same variable name
we'd still have the same issue.
llvm-svn: 357036
Summary:
This wasn't actually printing out a CMake warning, it was prepending
"WARN" to the message.
Reviewers: zturner
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59432
llvm-svn: 356297
Summary:
In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX
(ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html),
this patch adds customizations to the CMake files in order to properly
invoke the host toolchain for the build on AIX.
Additional changes to enable a successful build will follow.
Patch by Xing Xue
Reviewers: hubert.reinterpretcast, jasonliu, sfertile
Reviewed by: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D58250
llvm-svn: 356104
Summary:
AIX compilers define macros based on the version of the operating
system.
This patch implements updating of versionless AIX triples to include the
host AIX version. Also, the host triple detection in the build system is
adjusted to strip the AIX version information so that the run-time
detection is preferred.
Reviewers: xingxue, stefanp, nemanjai, jasonliu
Reviewed By: xingxue
Subscribers: mgorny, kristina, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58798
llvm-svn: 355995
When installing runtimes with install-runtimes-stripped, we don't want
to just strip them, we also want to preserve the debugging information
for potential debugging. To make it possible to later find the stripped
debugging information, we want to use the .build-id layout:
https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID
That is, for libfoo.so with build ID abcdef1234, the debugging information
will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy
already has support for stripping files and linking the debugging
stripped output into the right location. However, CMake doesn't support
customizing strip invocation for the *-stripped targets. So instead, we
replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with
the right command line flags.
Differential Revision: https://reviews.llvm.org/D59127
llvm-svn: 355765
Summary:
The date-based approach to detecting unsupported versions of libstdc++
does not handle bug fix releases of older versions. As an example, the
`__GLIBCXX__` value associated with version 5.1, `20150422`, is less
than the values associated with versions 4.8.5 and 4.9.3.
This patch adds secondary checks based on certain properties in
sufficiently new versions of libstdc++.
Reviewers: jfb, tstellar, rnk, sfertile, nemanjai
Reviewed By: jfb
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58682
llvm-svn: 355638
Part 4 of CSPGO changes:
(1) add support in cmake for cspgo build.
(2) fix an issue in big endian.
(3) test cases.
Differential Revision: https://reviews.llvm.org/D54175
llvm-svn: 355541
Getting rid of the name "optimization remarks" for anything that
involves handling remarks on the client side.
It's safer to do this now, before we get stuck with that name in all the
APIs and public interfaces we decide to export to users in the future.
This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now
generates `libRemarks.dylib` instead of `libOptRemarks.dylib`.
Differential Revision: https://reviews.llvm.org/D58535
llvm-svn: 355439
When using the umbrella llvm-libraries and clang-libraries targets, we
should export all library targets, otherwise they'll be part of our
distribution but not usable from the CMake package.
Differential Revision: https://reviews.llvm.org/D58862
llvm-svn: 355354
Summary:
Handle the case where LLVM_MAIN_SRC_DIR is not set and also use
LLVM_CMAKE_DIR for locating installed cmake files rather than
LLVM_CMAKE_PATH.
Reviewers: phosek, andrewrk, smeenai
Reviewed By: phosek, andrewrk, smeenai
Subscribers: mgorny, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D58204
llvm-svn: 354417
Compiler-rt doesn't include config-ix which was providing CheckSymbolExists to
the LLVM build. Add it to HandleLLVMOptions to fix this
llvm-svn: 354389
Surprisingly, check_symbol_exists is not sufficient. The macOS linker checks the
called functions against a compatibility list for the given deployment target
and check_symbol_exists doesn't trigger this check as it never calls the
function.
This fixes the GreenDragon bots where the deployment target is 10.9
llvm-svn: 354374
Summary:
Instruments is a useful tool for finding performance issues in LLVM but it can
be difficult to identify regions of interest on the timeline that we can use
to filter the profiler or allocations instrument. Xcode 10 and the latest
macOS/iOS/etc. added support for the os_signpost() API which allows us to
annotate the timeline with information that's meaningful to LLVM.
This patch causes timer start and end events to emit signposts. When used with
-time-passes, this causes the passes to be annotated on the Instruments timeline.
In addition to visually showing the duration of passes on the timeline, it also
allows us to filter the profile and allocations instrument down to an individual
pass allowing us to find the issues within that pass without being drowned out
by the noise from other parts of the compiler.
Using this in conjunction with the Time Profiler (in high frequency mode) and
the Allocations instrument is how I found the SparseBitVector that should have
been a BitVector and the DenseMap that could be replaced by a sorted vector a
couple months ago. I added NamedRegionTimers to TableGen and used the resulting
annotations to identify the slow portions of the Register Info Emitter. Some of
these were placed according to educated guesses while others were placed
according to hot functions from a previous profile. From there I filtered the
profile to a slow portion and the aforementioned issues stood out in the
profile.
To use this feature enable LLVM_SUPPORT_XCODE_SIGNPOSTS in CMake and run the
compiler under Instruments with -time-passes like so:
instruments -t 'Time Profiler' bin/llc -time-passes -o - input.ll'
Then open the resulting trace in Instruments.
There was a talk at WWDC 2018 that explained the feature which can be found at
https://developer.apple.com/videos/play/wwdc2018/405/ if you'd like to know
more about it.
Reviewers: bogner
Reviewed By: bogner
Subscribers: jdoerfert, mgorny, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D52954
llvm-svn: 354365
Modify LLVMConfig to provide split variables for in-source and generated
include paths. Currently, it uses a single value for both
LLVM_INCLUDE_DIRS and LLVM_INCLUDE_DIR which works for install tree but
fails hard at build tree (where LLVM_INCLUDE_DIR incorrectly contains
multiple values).
Instead, put the generated directory in LLVM_INCLUDE_DIR, and the source
tree in LLVM_MAIN_INCLUDE_DIR which is consistent with in-LLVM builds.
For install tree, both variables will have the same value.
Differential Revision: https://reviews.llvm.org/D58109
llvm-svn: 353924
Find dependent scripts of GenerateVersionFromVCS in current directory
rather than ../../cmake/modules. I do not see any reason why the former
would not work and The latter is incorrect when GenerateVersionFromVCS
is used from install directory (i.e. in stand-alone builds).
Differential Revision: https://reviews.llvm.org/D57996
llvm-svn: 353674
Summary:
The RFC on moving past C++11 got good traction:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
This patch therefore bumps the toolchain versions according to our policy:
llvm.org/docs/DeveloperPolicy.html#toolchain
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane
Differential Revision: https://reviews.llvm.org/D57264
llvm-svn: 353374
As far as I can tell, malloc.h is only being used here to provide
a definition of mallinfo (malloc itself is declared in stdlib.h via
cstdlib). We already have a macro for whether mallinfo is available,
so switch to using that instead.
Differential Revision: https://reviews.llvm.org/D57807
llvm-svn: 353329
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
llvm-svn: 353268
Reverting D57264 again, it looks like we're down to two bots that need fixing:
polly-amd64-linux
polly-arm-linux
They both have old versions of libstdc++ and recent clang.
llvm-svn: 352954
Summary:
The RFC on moving past C++11 got good traction:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
This patch therefore bumps the toolchain versions according to our policy:
llvm.org/docs/DeveloperPolicy.html#toolchain
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane
Differential Revision: https://reviews.llvm.org/D57264
llvm-svn: 352951
Summary: D56606 was only appending target names to the `LLVM_EXPORTS`/`LLVM_EXPORTS_BUILDTREE_ONLY` properties. Targets showed up correctly in the build-tree `LLVMExports.cmake`, but they were missing in the installed one (as we found in https://bugs.llvm.org/show_bug.cgi?id=40443), because install did not register them explicitly.
Reviewers: mgorny, smeenai, beanz, gottesmm, dschuff, tstellar, serge-sans-paille
Reviewed By: smeenai
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D57383
llvm-svn: 352869
Summary:
The RFC on moving past C++11 got good traction:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
This patch therefore bumps the toolchain versions according to our policy:
llvm.org/docs/DeveloperPolicy.html#toolchain
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane
Differential Revision: https://reviews.llvm.org/D57264
llvm-svn: 352834
A handful of bots are still breaking, either because I missed them in my audit,
they were offline, or something else. I'm contacting their authors, but I'll
revert for now and re-commit later.
llvm-svn: 352814
Summary:
The RFC on moving past C++11 got good traction:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
This patch therefore bumps the toolchain versions according to our policy:
llvm.org/docs/DeveloperPolicy.html#toolchain
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane
Differential Revision: https://reviews.llvm.org/D57264
llvm-svn: 352811
CMake 3.6 introduced CMAKE_TRY_COMPILE_PLATFORM_VARIABLES, which solves
precisely the problem that necessitated init_user_prop, so we can switch
over whenever we bump our minimum CMake requirement.
llvm-svn: 352790
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
llvm-svn: 352729
Summary: We added support for code signing entitlements in add_llvm_executable() with D54443. In the future it would be useful to have this functionality available also for libraries.
Reviewers: beanz, bogner
Reviewed By: bogner
Subscribers: mgorny, llvm-commits, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D57334
llvm-svn: 352628
Alex Langford