Discovered an issue working in StableHLO when attempting to build with `-Wall -Werror`:
https://github.com/openxla/stablehlo/pull/137
Currently, if `LLVM_USE_LLD` and `-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} -Wall -Werror"`
are both specified for build, the build will error with:
```
-- Performing Test CXX_SUPPORTS_CUSTOM_LINKER - Failed
CMake Error at /usr/local/google/home/gleasonk/Coding/llvm-build/lib/cmake/llvm/HandleLLVMOptions.cmake:309 (message):
Host compiler does not support '-fuse-ld=lld'
...
$ cat <build_dir>/CMakeFiles/CMakeError.log
...
clang: error: argument unused during compilation: '-fuse-ld=lld' [-Werror,-Wunused-command-line-argument]
```
It looks like other repos have hit this same issue:
- https://github.com/golang/go/issues/41527 (mentioned in comment)
- https://github.com/iree-org/iree/pull/7450
This can be reproduced in llvm-project with the following build command:
```
# Compile command taken from https://mlir.llvm.org/getting_started/
# and modified for use case
cmake -G Ninja ../llvm \
-DLLVM_ENABLE_PROJECTS=mlir \
-DLLVM_BUILD_EXAMPLES=ON \
-DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU" \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_ASSERTIONS=ON \
-DCMAKE_CXX_COMPILER=clang++ \
-DCMAKE_C_COMPILER=clang \
-DLLVM_ENABLE_LLD=ON \
-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} -Wall -Werror"
```
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D134206
We do keep using the flag with Clang, which should keep catching
such issues in buildbots.
With GCC, the warning can cause lots of loud notes about the
warning logic getting disabled in large source files.
Differential Revision: https://reviews.llvm.org/D132914
Warns on potentially unintended use of C++17 Class Template Argument
Deduction. Use of this feature with types that aren't intended to
support it may may future refactorings of those types more difficult -
so this warning fires whenever the feature is used with a type that may
not have intended to be used with CTAD (the warning uses the existence
of at least one explicit deduction guide to indicate that a type
intentionally supports CTAD - absent that, it's assumed to not be
intended to support CTAD & produces a warning).
This is disabled in libcxx because lots of the standard library is
assumed to provide ctad-usable APIs and the false positive suppression
in the diagnostic is based on system header classification which doesn't
apply in the libcxx build itself.
Differential Revision: https://reviews.llvm.org/D131727
Since c5b3de6745 (git main,
August 11th), Clang does generate working hidden visibility
on MinGW targets. Using that reduces the number of exports from
a dylib build of LLVM significantly, which is vital for fitting
within the limit of 64k exported symbols from a DLL.
It's essential that if we set CMAKE_CXX_VISIBILITY_PRESET=hidden
(which passes -fvisibility=hidden on the command line), we also
must define LLVM_EXTERNAL_VISIBILITY consistently to override
it. (If there are mismatches, e.g. setting hidden visibility generally
but never overriding it back to default for the symbols that do need
to be exported, we'd get broken builds in such configurations.)
We don't want to be using __attribute__((visibility("hidden"))) on
MinGW with GCC, because GCC produces a warning about it. (GCC hasn't
warned about the command line options that set hidden visibility
though.) Clang has historically not warned about either of them, so
it is harmless to use the hidden visibility when building with older
Clang (so we don't need to detect the exact version of Clang/LLVM where
it has an effect).
This reduces the number of exported symbols for a dylib build of LLVM;
previously libLLVM exported around 64650 symbols (when the maximum is
65536) when the ARM, AArch64 and X86 targets were enabled. If enabling
more targets (or if building with e.g. assertions enabled), it would
exceed the limit. Now with visibility flags in use, the same build
with ARM, AArch64 and X86 ends up at around 35k exported symbols.
Differential Revision: https://reviews.llvm.org/D131661
In the top-level llvm `CMakeLists.txt`, we need to call
`find_package(Python3)` *before* including `config-ix.cmake`, otherwise
the latter will not be able to successfully search for python modules
using `find_python_module()`. Also set `LLVM_MINIMUM_PYTHON_VERSION`
before calling `find_package(Python3)`, moving it to `CMakeLists.txt`
from `HandleLLVMOptions.cmake`.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D131191
I wondered why I hadn't seen the link failures in D130571
<https://reviews.llvm.org/D130571> on Solaris/sparcv9 and found that
Solaris, unlike Linux, doesn't use `-Wl,-z,defs` when linking shared
objects. The three affected shared objects indeed have undefined
references to several 64-bit atomics.
This patch will expose such issues in the future by defaulting to
`-Wl,-z,defs` on Solaris, as recommended in `ld(1)`.
Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D130572
Add a new CMake file to expand on for more problematic configurations
in the future.
Related to #54645
Reviewed By: beanz, phosek, smeenai
Differential Revision: https://reviews.llvm.org/D123777
Place PersistentId declaration under #if LLVM_ENABLE_ABI_BREAKING_CHECKS to
reduce memory usage when it is not needed.
Differential Revision: https://reviews.llvm.org/D120714
This option tells the host clang to use the new pass manager.
Given that it's been the default for a while, this seems unnecessary.
This was added in D57068.
(this does not affect any LLVM/Clang functionality)
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D122947
This allows you to set a custom path to the ThinLTO cache so that
it can be shared when building in several different build directories.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D121215
* Use `MATCHES` so that `Ninja Multi-Config` generator also satisfies the Ninja check
* Pull out a couple of values into variables, inside `function(tablegen project ofn)`, NFC
Differential Revision: https://reviews.llvm.org/D118100
/INCREMENTAL is the linker default (lld-link and MSVC link). Specifying
"/INCREMENTAL:NO" is the only way to disable it. So checking for the
negative flag instead and check exe/module/shared link flags
independently.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D117381
Clang 13 has a -fsanitize-coverage -fno-semantic-interposition bug (D117190)
which may lead to
`relocation R_X86_64_PC32 cannot be used against symbol` linker error
in -DLLVM_USE_SANITIZE_COVERAGE=ON build when a shared object is built (e.g.
-DLLVM_BUILD_LLVM_DYLIB=on).
For simplicity, just disallow Clang 13 entirely.
Note: GCC -fPIC performance benefits from -fno-semantic-interposition
dramatically. Clang benefits little. Using this option is more for a dogfood
purpose to test correctness of this option, because in the wild some important
packages like CPython uses this option.
Differential Revision: https://reviews.llvm.org/D117183
This diff enables users to override CMAKE_C_ARCHIVE_CREATE & CMAKE_CXX_ARCHIVE_CREATE
(currently set in HandleLLVMOptions.cmake).
For example, one can specify
cmake -DCMAKE_C_ARCHIVE_CREATE="<CMAKE_AR> TDqc <TARGET> <LINK_FLAGS> <OBJECTS>" \
-DCMAKE_CXX_ARCHIVE_CREATE="<CMAKE_AR> TDqc <TARGET> <LINK_FLAGS> <OBJECTS>" ...
to make the build create thin archives instead of regular ones.
For a clean run `ninja lld` using thin archives seems to reduce the size
of the build directory from ~14GB to ~8GB
Differential revision: https://reviews.llvm.org/D116850
This patch changes it to ignorelist and contains a filename change for the
.txt file that's called.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D113689
Visibility options currently have limited support on AIX and may cause warnings or errors
depending on the build compiler used.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D108467
This updates llvm/utils/sysroot.py to include the "DIA SDK" folder in the
sysroot.
It also updates the build to look for the DIA SDK there if a sysroot is set.
This requires moving LLVM_WINSYSROOT to config-ix.cmake.
For the GN build, I chose to pass a qualified path to diaguids in libs instead
of pushing a config with a `/libpath:` flag. The former requires a GN with
https://gn-review.googlesource.com/c/gn/+/12200, the latter requires D109624.
The former is more like the cmake build, arguably a bit simpler, and it's
easier to check for the wrong GN revision and easier to update GN.
Differential Revision: https://reviews.llvm.org/D109708
`-fno-semantic-interposition` was added for GCC in D102453, but some MLIR tests
on SystemZ failed with GCC<10.3 due to a bug.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D105453
In a `-DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_LINK_LLVM_DYLIB=on -DCLANG_LINK_CLANG_DYLIB=on`
build, libLLVM-13git.so is 2% smaller and libclang-cpp.so is 1% smaller (on top of -Wl,-Bsymbolic-functions).
There may be some small performance improvement as well because GCC
-fPIC suppresses interprocedural optimizations for non-inline
definitions by default.
Note: we cannot add -fno-semantic-interposition for Clang<13. Clang<13's
implementation additionally optimizes global variables, which is incompatible
with unfortunate ELF -fno-pic default: direct access relocations for external
data. If the executable has a -fno-pic object file referencing a global variable
declared in a public header, the direct access relocation will cause a copy
relocation. The executable and libLLVM.so/libclang-cpp.so will disagree on the
address.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D102453
This precomputes some hashes that LLD uses for type merging to speed up
linking when PDBs are enabled. Only do this if any kind of /DEBUG flag
is passed to the linker. -gcodeview-ghash is orthogonal to /Z7, -g, -g1,
or -gmlt, so it is safe to set it independently from those flags. It
will not increase debug info emission.
Differential Revision: https://reviews.llvm.org/D103287
It's easy to hit 2**16 limit with i686 GNU toolchains these days.
Clang does it automagically, so it's not needed there, and the option
causes warnings about being unused when linking.
Differential Revision: https://reviews.llvm.org/D102419
llvm-dev message: https://lists.llvm.org/pipermail/llvm-dev/2021-May/150465.html
In an ELF shared object, a default visibility defined symbol is preemptible by default.
This creates some missed optimization opportunities. -fno-semantic-interposition can optimize -fPIC:
* in Clang: avoid GOT/PLT cost for variable access/function calls to external linkage definition in the same TU
* in GCC: enable interprocedural optimizations (including inlining) and avoid PLT
See https://gist.github.com/MaskRay/2d4dfcfc897341163f734afb59f689c6 for more information.
-Bsymbolic-functions is more aggressive than -fvisibility-inlines-hidden (present since 2012) as it applies
to all function definitions. It can
* avoid PLT for cross-TU function calls && reduce dynamic symbol lookup
* reduce dynamic symbol lookup for taking function addresses and optimize out GOT/TOC on x86-64/ppc64
With both options, the libLLVM.so and libclang-cpp.so performance should
be closer to PIE binary linking against `libLLVM*.a` and `libclang*.a`
(In a -DLLVM_TARGETS_TO_BUILD=X86 build, the number of JUMP_SLOT decreases from 12716 to 1628, and the number of GLOB_DAT decreases from 1918 to 1313
The built clang with `-DLLVM_LINK_LLVM_DYLIB=on -DCLANG_LINK_CLANG_DYLIB=on` is significantly faster.
See the Linux kernel build result https://bugs.archlinux.org/task/70697
)
Some implication:
Interposing a subset of functions is no longer supported.
(This is fragile anyway and cannot really be supported. For Mach-O we don't use
`ld -interpose`, so interposition is not supported on Mach-O at all.)
Compiling a program which takes the address of any LLVM function with
`{gcc,clang} -fno-pic` and expects the address to equal to the address taken
from libLLVM.so or libclang-cpp.so is unsupported. I am fairly confident that
llvm-project shouldn't have different behaviors depending on such pointer
equality (as we've been using -fvisibility-inlines-hidden which applies to
inline functions for a long time), but if we accidentally do, users should be
aware that they should not make assumption on pointer equality in `-fno-pic`
mode.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D102090
If compiling with GCC or linking with ld.bfd, these options have little
effect, but if built with Clang and linked with LLD, they provide a
quite notable size decrease - this shrinks an entire llvm-mingw
distribution package by 22%.
If building with BUILD_SHARED_LIBS or LLVM_BUILD_LLVM_DYLIB with LLD,
this requires a version of LLD that contains a fix for auto exporting
symbols from comdats, 2b01a417d7.
Differential Revision: https://reviews.llvm.org/D101568
Match the API for the new check_linker_flag and use it directly when
available, leaving the old code as a fallback.
Differential Revision: https://reviews.llvm.org/D100901
Changing global flags can break builds of projects that include/build
llvm as a sub-project, as the effect is global. Ideally we would
disable this warning at the directory level instead, but the obvious
way (disabling warning D9025) isn't supported. At least we can limit
the effect to only MSVC.
Patch by Jim Radford.
Differential Revision: https://reviews.llvm.org/D100900
Similar to the existing code for disabling GCC's -Wredudant-move,
also check for the -Wpessimizing-move option and disable it if
possible.
This silences another bunch of noisy warnings when building LLVM
with GCC 9.
As noted for -Wredundant-move, the code can't be fixed to silence the
warnings while retaining support for older compilers.
Differential Revision: https://reviews.llvm.org/D98942
BUILD_SHARED_LIBS build llvm component as shared library,
which can reduce the size a lot.
Normally, the binary use ORIGIN../lib to load component libraries,
unfortunatly, ORIGIN is not supported by AIX ld.
We hardcoded the build lib and install lib path in rpath for now
to enable BUILD_SHARED_LIBS build.
Understand that this is not perfect solution,
we can update this when we find better solution.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D98901
This matches what GCC warns about when -pedantic is enabled.
This should avoid such redundant semicolons creeping into the codebase.
Differential Revision: https://reviews.llvm.org/D98941
The current cmake script attempts to add the path containing clangs various runtime systems by getting the resource directory and then appending the hardcoded value /lib/windows to it. This works for a normal clang-cl build but fails for a build of clang using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR, such as the builds from llvm/runtimes.
This patch instead uses -print-libgcc-file-name in conjunction with --rtlib=compiler-rt, and instead adds the containing directory as library path.
For non per-target runtime directory builds, such as the release builds, there is no change. Even if the builtins library were to be deleted or moved it would output the same path as before.
For per-target runtime builds that also have the builtins library, this now finds the correct directory containing all of clang runtime libraries.
Only case still not handled by this change, is if a per-target runtime directory build is used, but the builtins library was not built.
I believe that is the best we can do for now however, without modifying clang.
Differential Revision: https://reviews.llvm.org/D98786
The lit test suite uses python 3.6 features. Rather than a strange
python syntax error upon running the lit tests, we will require the
correct version in CMake.
Reviewed By: serge-sans-paille, yln
Differential Revision: https://reviews.llvm.org/D95635
Turn `-Wreturn-type` into an error.
This is currently used by libcxx, libcxxabi, and libunwind, and would be a good default
for all of llvm. I'm not aware of any cases where this shouldn't be an error. This
ensures different build configs, merges, and downstream branches catch issues sooner.
Differential Revision: https://reviews.llvm.org/D98224
Kevin Gleason