so that it gets installed in LLVM_INSTALL_TOOLCHAIN_ONLY builds,
such as used by the Windows installer.
Differential revision: https://reviews.llvm.org/D109358
(cherry picked from commit c364dcbf1fd81c6291e935564fce2d9ebb97a3d0)
Include the vaue of LLVM_ENABLE_NEW_PASS_MANAGER in generated
LLVMConfig.cmake since it is needed by clang's build system. This fixes
test failures when the new pass manager is enabled (i.e. by default)
by having clang's CMake files correctly detect that and skip relevant
tests.
Differential Revision: https://reviews.llvm.org/D107628
(cherry picked from commit 889a1e69bd2d65c368712ec653450099446aed33)
Currently when linking LLVM against Libxml2, a simple check is performed to check whether it can be linked successfully. This check currently adds the include directories and the libraries for libxml2, but not definitions found by the config.
This causes issues on Windows when trying to link against a static libxml2. Libxml2 requires LIBXML_STATIC to be defined in the preprocessor to be able to link statically. This definition is put into LIBXML2_DEFINITIONS in the cmake config, but not properly forwarded to check_symbol_exists leading to it failing as it could not find xmlReadMemory in a DLL.
This patch simply appends the content of LIBXML2_DEFINITIONS to the symbol check definitions, fixing the issue.
Differential Revision: https://reviews.llvm.org/D106740
This is just a workaround. Pass the `-mllvm,-O0` link flags only if its
not ThinLTO. Doing that with ThinLTO currently results in an error:
```
Remaining virtual register operands
UNREACHABLE executed at .../llvm/lib/CodeGen/MachineRegisterInfo.cpp:209!
```
This is referenced in several of the cmake files that are part of an llvm install and it is also useful by downstream components such as onnx-mlir.
Differential Revision: https://reviews.llvm.org/D106686
This patch adds llvm-readobj and the binutils symlink for readelf to
LLVM_TOOLCHAIN_TOOLS.
Tvoid *thread, void *attr,hey are required by some (most?)
autoconf-built libraries, adding these allows me to build newlib with
the toolchain generated this way.
Also opened an issue for that some days ago, see
https://bugs.llvm.org/show_bug.cgi?id=50698
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D104957
`-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
`llvm-strip` does not support `-l`. Apple's `strip` supports `-l`, but
it is not documented, and the latest code doesn't seem to do anything
meaningful. From the old source code drops it seems that `-l` was added
around version 795 of cctools and removed before 898. The code around
the flag usage in 795 talks about problems with kext and forcing the
execution of `ld -r`, which seems a behaviour that is not enforceable in
latest versions of cctools.
The `-l` flag was added in https://reviews.llvm.org/D15133 without a lot
of explanation.
Since the flag is not active, removing it should not modify the
behaviour for most people (except if someone is trying to compile LLVM
with a really old version of `strip`).
Additionally, break the invocation into two different flags, since
`llvm-strip` doesn't at the moment support grouped flags, and other
`strip` implementations should work the same no matter if grouped or
not.
Test Plan:
Using `strip` from Xcode 12.5 in Big Sur to strip the same binary (a
simple Hello World), using both `-Sxl` and `-Sx` produces exactly the
same binary.
Repeating the same process with `clang` results also in the same binary.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D105243
Synchronizing multiple custom targets requires not only target but also
file dependencies. Building Linalg involves running yaml-gen followed by
tablegen. Currently, these custom targets are only synchronized using a
target dependency resulting in issues in specific incremental build
setups (https://llvm.discourse.group/t/missing-build-cmake-tblgen-dependency/3727/10).
This patch introduces a novel LLVM_TARGET_DEPENDS variable to the
TableGen.cmake file to provide a way to specify file dependencies.
Additionally, it adapts the Linalg CMakeLists.txt to introduce the
necessary file dependency between yaml-gen and tablegen.
Differential Revision: https://reviews.llvm.org/D105272
They are not conducive to being stored in git. Instead, we autogenerate
mock model artifacts for use in tests. Production models can be
specified with the cmake flag LLVM_INLINER_MODEL_PATH.
LLVM_INLINER_MODEL_PATH has two sentinel values:
- download, which will download the most recent compatible model.
- autogenerate, which will autogenerate a "fake" model for testing the
model uptake infrastructure.
Differential Revision: https://reviews.llvm.org/D104251
If the flag is not set, the script saved_model_aot_compile.py in tensorflow will
default it to the correct value. However, in TF 2.5, the way the value is set in
TensorFlowCompile.cmake file triggers a build error.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D103972
This is an attempt to fix clang test failures due to 'nonportable-include-path'
warnings on Windows when a path to llvm-project's base directory contains some
uppercase letters (excluding a drive letter).
The issue originates from 2 problems:
* discovery.py loads site config in lower case causing all the paths
based on __file__ and requested within the config file to be in lowercase as well,
* neither os.path.abspath() nor os.path.realpath() (both used to obtain paths of
config files, sources, object directories, etc) do not return paths in the correct
case for Windows (at least consistently for all python versions).
As os.path library doesn't seem to provide any relaible way to restore
the case for paths on Windows, this patch proposes to use pathlib.resolve().
pathlib is a part of Python 3.4 while llvm lit requires Python 3.6.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D103014
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
lld/MachO/Driver.cpp and lld/MachO/SyntheticSections.cpp include
llvm/Config/config.h which doesn't exist when building standalone lld.
This patch replaces llvm/Config/config.h include with llvm/Config/llvm-config.h
just like it is in lld/ELF/Driver.cpp and HAVE_LIBXAR with LLVM_HAVE_LIXAR and
moves LLVM_HAVE_LIBXAR from config.h to llvm-config.h
Also it adds LLVM_HAVE_LIBXAR to LLVMConfig.cmake and links liblldMachO2.so
with XAR_LIB if LLVM_HAVE_LIBXAR is set.
Differential Revision: https://reviews.llvm.org/D102084
We already use -O0 for unittests under ThinLTO, do the same for full LTO
where the compile time costs to runtime benefits tradeoff is even worse.
Differential Revision: https://reviews.llvm.org/D102718
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's build system contains support for configuring a distribution, but
it can often be useful to be able to configure multiple distributions
(e.g. if you want separate distributions for the tools and the
libraries). Add this support to the build system, along with
documentation and usage examples.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D89177
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, 2b01a417d7ccb001ccc1185ef5fdc967c9fac8d7.
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
This allows one to cross-compile the header/object for a model in a
setup where the compiler is built on a system that cannot host the AOT
compiler. For example, if arm-hostable clang is desired, while the AOT
Tensorflow compiler can cross-compile to arm, it can't currently run on
arm.
The only alternative in that scenario would be to cross-compile clang
itself, but that gets complicated when trying to run tests after that.
Differential Revision: https://reviews.llvm.org/D99992
This makes it possible to build libLLVM.so without first creating a
static library for each component. In the case where only libLLVM.so is
built (i.e. ninja LLVM) this eliminates 150 linker jobs.
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D95727
Use the CMake 3.13 features of CMakeConfigPackageHelpers to generate
LLVMConfigVersion.cmake with proper architecture detection, major+minor
version matching, etc.
Differential Revision: https://reviews.llvm.org/D99451
Call `get_errc_messages` only if `LLVM_INCLUDE_TESTS` was set.
Reviewed By: zero9178, abhina.sreeskantharajan, jhenderson
Differential Revision: https://reviews.llvm.org/D98861
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
If for some reason the test program does not exit normally it'd currently lead to a false positive and it's stdout output being assigned to the output variable.
Instead, check the test program exited normally before assigning the process output to the out variable.
Follow up on rGaf2796c76d2ff4b73165ed47959afd35a769beee
Fixes an issue discovered post commit in https://reviews.llvm.org/D98278
Visual Studios implementation of the C++ Standard Library does not use strerror to produce a message for std::error_code unlike other standard libraries such as libstdc++ or libc++ that might be used.
This patch adds a cmake script that through running a C++ program gets the error messages for the POSIX error codes and passes them onto lit through an optional config parameter.
If the config parameter is not set, or getting the messages failed, due to say a cross compiling configuration without an emulator, it will fall back to using pythons strerror functions.
Differential Revision: https://reviews.llvm.org/D98278
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
