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
The original change to add the workaround is from 10 years ago and a lot has happened with msvc and cmake and llvm's usage of cmake since and we no longer need the workaround for any scenarios that I am aware of. Build more is now correctly configured for multi-configuration generators such as Visual Studio.
The workaround is, however, causing issues with some of the recent mlir tests as because of the workaround we cannot correctly determine whether assertions are enabled (see https://reviews.llvm.org/D105961).
The original change is:
```
commit b46fdac460
Author: Andrew Trick <atrick@apple.com>
Date: Tue Jun 28 16:32:01 2011
cmake: Our MSVC build does not support config-time build mode.
llvm-svn: 134008
```
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D109521
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
This is a pretty small bit of CMake goop to generate code coverage
reports. I always forget the right script invocation and end up
fumbling around too much.
Wouldn't it be great to have targets that "Just Work"?
Well, I thought so.
At present this only really works correctly for LLVM, but I'll extend
it in subsequent patches to work for subprojects.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D109019
After some moment VS solution generated with LLVM_OPTIMIZED_TABLEGEN started to
generate all .inc files for each build. The reason was it had
"<path to native tablegen>/llvm-tblgen" without .exe as a dependency.
Differential Revision: https://reviews.llvm.org/D107898
It's sometimes useful to use these directives when dealing with
external projects:
target_link_directories
target_link_libraries
target_include_directories
However, under certain circumstances,
llvm_add_library can generate multiple targets. We need to transfer
these properties to the new targets. Note that using a generator
expression is necessary because these properties will only be set
after llvm_add_library is called.
Differential Revision: https://reviews.llvm.org/D108098
Consistently use 'w64' as vendor string; it was 'pc' for the original
i686 triple added in 91bd6c922d, but the later x86_64 triple
used 'w64' as vendor, added in d6c1f37f86.
When the arm triples were added in c84ad73a27, the differing
vendors were copied over accidentally to the arm targets too.
When using per-target runtime directories, having inconsistent vendor
parts of the target triples is fatal.
Differential Revision: https://reviews.llvm.org/D107894
In MSVC mode, CMake provides CMAKE_C_COMPILER_ARCHITECTURE_ID,
which should be accurate for what the compiler produces. Keep
the old CMAKE_C_SIZEOF_VOID_P based fallback in case this
doesn't provide matches.
In GCC/MinGW mode, CMake doesn't provide that. As we're trying to
guess the default host architecture, use CMAKE_HOST_SYSTEM_PROCESSOR
in combination with the existing CMAKE_C_SIZEOF_VOID_P check to
estimate whether it's x86/x86_64/arm/aarch64.
Differential Revision: https://reviews.llvm.org/D107626
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
Use absolute path to link z3 to allow builds both on windows and linux
since the library name is platform dependent for Z3 (libz3 on Windows
and z3 on Linux) and MSVC does not recognized -L and -l options.
Fix CMAKE_CROSSCOMPILING that does not work correctly since it uses
Z3_BUILD_VERSION instead of Z3_BUILD_NUMBER
Fix building with the static version of z3 library (supersedes D80227).
- Build the Z3 version detection code as C++, since the static
library brings in libstdc++ symbols
- Detect threading support and link against threading, in the
(likely) case Z3 was built with threads
Exposed compilation error from building a program that is used to detect
z3 version in the warning message, to simplify troubleshooting.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D106131
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, 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
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
David Tenty