LLVM currently assumes that Apple platforms will always use ld64. In the
future, LLD Mach-O might also be supported, so add the beginnings of
linker detection support. ld64 is currently the only detected linker,
since `ld64.lld -v` doesn't yield any useful version output, but we can
add that detection later, and in the meantime it's still useful to have
the ld64 identification.
Switch clang's order file check to use this new detection rather than
just checking for the presence of an ld64 executable.
Differential Revision: https://reviews.llvm.org/D48201
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334780 91177308-0d34-0410-b5e6-96231b3b80d8
On MacOS, if CMAKE_OSX_SYSROOT is used and the user has command line tools
installed, we currently get the include path for libxml2 as
/usr/include/libxml2, instead of ${CMAKE_OSX_SYSROOT}/usr/include/libxml2.
Make it consistent on MacOS by prefixing ${CMAKE_OSX_SYSROOT} when
possible.
rdar://problem/41103601
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334746 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The macro parses out the USE_SHARED option out of the argument list, but
then ignores it and accesses the variable with the same name instead. It
seems the intention here was to check the argument value.
Technically, this is NFC, because the only in-tree usage
(add_llvm_executable) of USE_SHARED sets both the variable and the
argument when calling llvm_config, but it makes the usage of this macro
for out-of-tree users more sensible.
Reviewers: mgorny, beanz
Reviewed By: mgorny
Subscribers: foutrelis, llvm-commits
Differential Revision: https://reviews.llvm.org/D44420
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334082 91177308-0d34-0410-b5e6-96231b3b80d8
The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target,
and in the future also to control the search path directly; as such it
should be used textually, without interpretation by LLVM.
Normalization of this value may lead to unexpected results, for example
if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu,
normalization will transform that value to x86_64--linux-gnu. Driver will
use that value to search for tools prefixed with x86_64--linux-gnu- which
may be confusing. This is also inconsistent with the behavior of the
--target flag which is taken as-is without any normalization and overrides
the value of LLVM_DEFAULT_TARGET_TRIPLE.
Users of sys::getDefaultTargetTriple already perform their own
normalization as needed, so this change shouldn't impact existing logic.
Differential Revision: https://reviews.llvm.org/D46910
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332750 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332628 91177308-0d34-0410-b5e6-96231b3b80d8
Don't hardcode objcopy and strip names, rather use CMAKE_OBJCOPY and
CMAKE_STRIP variables which allows users to override the tools used
such as using llvm-objcopy and llvm-strip instead of binutils versions.
Differential Revision: https://reviews.llvm.org/D46611
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331827 91177308-0d34-0410-b5e6-96231b3b80d8
This change causes us to re-run tablegen for every single target on
every single build. This is much, much worse than the problem being
fixed AFAICT.
On my system, it makes a clean rebuild of `llc` with nothing changed go
from .5s to over 8s. On systems with less parallelism, slower file
systems, or high process startup overhead this will be even more
extreme.
The only way I see this could be a win is in clean builds where we churn
the filesystem. But I think incremental rebuild is more important, and
so if we want to re-instate this, it needs to be done in a way that
doesn't trigger constant re-runs of tablegen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331702 91177308-0d34-0410-b5e6-96231b3b80d8
These are necessary changes to support building LLVM for Fuchsia.
While these are not sufficient to run on Fuchsia, they are still
useful when cross-compiling LLVM libraries and runtimes for Fuchsia.
Differential Revision: https://reviews.llvm.org/D46345
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331423 91177308-0d34-0410-b5e6-96231b3b80d8
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
I replaced all uses of LLVM_ON_WIN32 with _WIN32 in r331127 (llvm),
r331069 (clang), r329697 (lldb), r329696 (lld), r329696 (clang-tools-extra).
If your out-of-tree program used LLVM_ON_WIN32, just use _WIN32 instead, which
is set at exactly the same time to exactly the same value.
https://reviews.llvm.org/D46264
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331224 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM might be compiled using a toolchain file which controls the linker
to use via flags (e.g. `-B` or `-fuse-ld=`). Take these flags into
account for linker detection. We can also correct the detection by
manually passing LLVM_USE_LINKER, of course, but it seems more
convenient to have the detection take flags into account.
Differential Revision: https://reviews.llvm.org/D45464
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330924 91177308-0d34-0410-b5e6-96231b3b80d8
-stdlib=libc++ is added to both the compilation and the link flags, but
the logic for adding it was only checking if it was supported during
compilation and not linking. This could lead to false positives, for
example when using clang with libstdc++ (where the compiler would
support -stdlib=libc++ but then linking would fail because of libc++
actually being unavailable).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330761 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Due to some android peculiarities, in some build configurations
(statically linked executables targeting older releases) we could detect
the presence of these functions (because they are present in libc.a,
where check_library_exists searches), but then fail to build because the
headers did not include the definition.
This attempts to remedy that by upgrading the check_library_exists to
check_symbol_exists, which will check that the function is declared too.
I am hoping that a more thorough check will make the messy #ifdef we
have accumulated in the code obsolete, so I optimistically try to remove
them.
Reviewers: zturner, kparzysz, danalbert
Subscribers: srhines, mgorny, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D45359
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330251 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts SVN r330158.
Seems that there was a change to linker flags handling in SVN r316972.
That would alter the behaviour to correct the linker flag handling in
CMake (requiring CMake 3.4.3+). Since that is already the minimum
version required for LLVM, hard coding the knowledge of the linker is
not required, which is a strictly better solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330161 91177308-0d34-0410-b5e6-96231b3b80d8
When building out-of-tree compilers (e.g. swift), the linker check here
may yield incorrect values. Ensure that we are using lld before we
attempt to use `--color-diagnostics` for the linker. Other linkers (i.e
bfd, gold) do not support this flag and the test can pass in some cases
and then fail subsequently when building.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330158 91177308-0d34-0410-b5e6-96231b3b80d8
These used to be set in the old autoconf build, but the cmake build has had a
"TODO: actually check for these" comment since it was checked in, and they
were set to 1 on mingw unconditionally. It seems safe to say that they always
exist under mingw, so just remove them and assume they're set exactly when on
mingw (with msvc, we use `pragma comment` instead of linking these via flags).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328992 91177308-0d34-0410-b5e6-96231b3b80d8
The autoconf manual: "This macro is obsolescent, as all current systems with
directory libraries have <dirent.h>. New programs need not use this macro."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328989 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328970 91177308-0d34-0410-b5e6-96231b3b80d8
Found by looking through the output of
for f in $(grep -o '\bHAVE_[A-Z0-9_]*\b' llvm/cmake/config-ix.cmake); do
echo $f $(git grep $f '*' | wc -l);
done
in the monorepo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328957 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version.
Like patch https://reviews.llvm.org/D41808, I propose that we rename libLLVM-7.0svn.so to libLLVM-7svn.so
This patch will also rename downstream libraries like liblldb-7.0 to liblldb-7
Reviewers: axw, beanz, dim, hans
Reviewed By: dim, hans
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D41869
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328768 91177308-0d34-0410-b5e6-96231b3b80d8
Cmake function llvm_check_source_file_list currently only accepts paths
relative to current CMAKE_SOURCE_DIR or relative to argument SOURCE_DIR.
Extend it to accept any path, including absolute ones.
Differential revision: https://reviews.llvm.org/D44625
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327912 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is needed so that external projects (e.g. a standalone build of
lldb) can link to the LLVM shared library via the USE_SHARED argument of
llvm_config. Without this, llvm_config would add LLVM to the link list,
but then also add the constituent static libraries, resulting in
multiply defined symbols.
Reviewers: beanz, mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44391
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327484 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Build system changes for RISCV. Makes it possible to build just the RISCV target alone.
Reviewers: asb, apazos, mgrang, beanz
Reviewed By: asb
Subscribers: mgorny, kito-cheng, shiva0217, llvm-commits
Differential Revision: https://reviews.llvm.org/D44153
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327423 91177308-0d34-0410-b5e6-96231b3b80d8
Append -Wl,-rpath-link conditionally to whether GNU ld.bfd is used
rather than the Linux+!gold conditionals. Also move it out of 'else'
branch of *BSD handling. This fixes build failures with ld.bfd
on Gentoo/FreeBSD, and should cause no harm on other systems using
ld.bfd.
This patch improves the original logic by reusing results of linker
detection introduced in r307852.
Differential Revision: https://reviews.llvm.org/D43751
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327007 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
This re-commit fixes a missing include of <vector> which it seems clang didn't
mind but G++ and MSVC objected to. It seems that, clang was ok with std::vector
only being forward declared at the point of use since it was fully defined
eventually but G++/MSVC both rejected it at the point of use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326738 91177308-0d34-0410-b5e6-96231b3b80d8
Despite building cleanly on my machine in three separate configs, it's failing on pretty much all bots due to missing includes among other things. Investigating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326726 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It can be useful for tools to be able to retrieve the values of variables
declared via STATISTIC() directly without having to emit them and parse
them back. Use cases include:
* Needing to report specific statistics to a test harness
* Wanting to post-process statistics. For example, to produce a percentage of
functions that were fully selected by GlobalISel
Make this possible by adding llvm::GetStatistics() which returns an
iterator_range that can be used to inspect the statistics that have been
touched during execution. When statistics are disabled (NDEBUG and not
LLVM_ENABLE_STATISTICS) this method will return an empty range.
This patch doesn't address the effect of multiple compilations within the same
process. In such situations, the statistics will be cumulative for all
compilations up to the GetStatistics() call.
Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner
Reviewed By: rtereshin, bogner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D43901
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326723 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables PDB generation for Release build, which has
slightly different optimize option with RelWithDebInfo on windows.
This helps to know slow part of Release build when profiling.
Patch by Takuto Ikuta
Differential Revision: https://reviews.llvm.org/D42632
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324504 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Rename LLVM_CONFIG_EXE to LLVM_CONFIG_PATH, and avoid building it if
passed in by user. This is the same way CLANG_TABLEGEN and
LLVM_TABLEGEN are handled, e.g., when -DLLVM_OPTIMIZED_TABLEGEN=ON is
passed.
Differential Revision: https://reviews.llvm.org/D41806
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323053 91177308-0d34-0410-b5e6-96231b3b80d8
Include the LLVM_LIBXML2_ENABLED cache variable in LLVMConfig.cmake
in order to make it available for other LLVM packages to query. This
is necessary to fix stand-alone testing of LLD.
Differential Revision: https://reviews.llvm.org/D42252
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322973 91177308-0d34-0410-b5e6-96231b3b80d8
