On Apple platforms the builtins may be built for both arm64 and arm64e.
With Makefile generators separate targets are built using Make sub-invocations.
This causes a race when creating the symlink which may sometimes fail.
Work around this by using a custom target that the builtin targets depend on.
This causes any sub-invocations to depend on the symlinks having been created before.
Mailing list thread: https://lists.llvm.org/pipermail/llvm-dev/2021-July/151822.html
Reviewed By: thakis, steven_wu
Differential Revision: https://reviews.llvm.org/D106305
cmake-3.16+ for AIX changes the default behavior of building a `SHARED` library which breaks AIX's build of libatomic, i.e., cmake-3.16+ builds `SHARED` as an archive of dynamic libraries. To fix it, we have to build `libatomic.so.1` as `MODULE` which keeps `libatomic.so.1` as an normal dynamic library.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D103786
When toolchain can supports all of arm, armhf and armv6m architectures compiler-rt
libraries won't compile because architecture specific flags are appended to single
BUILTIN_CFLAGS variable.
Differential revision: https://reviews.llvm.org/D103363
On AIX, we have to ship `libatomic.a` for compatibility. First, a new `clang_rt.atomic` is added. Second, use added cmake modules for AIX, we are able to build a compatible libatomic.a for AIX. The second step can't be perfectly implemented with cmake now since AIX's archive approach is kinda unique, i.e., archiving shared libraries into a static archive file.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D102155
Trying to build the builtins code fails because `arm64_32_SOURCES` is
missing. Setting it to the same list used for `aarch64_SOURCES` solves
that problem and allow the builtins to compile for that architecture.
Additionally, arm64_32 is added as a possible architecture for watchos
platforms.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D99690
This fixes detection when linking isn't supported (i.e. while building
builtins the first time).
Since 8368e4d54c, after setting
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY, this isn't strictly
needed, but is good for correctness anyway (and in case that commit
ends up reverted).
Differential Revision: https://reviews.llvm.org/D98737
Previously, that configuration only used the generic sources, in
addition to the couple specifically chosen arm/mingw files.
Differential Revision: https://reviews.llvm.org/D98547
When building builtins, the toolchain might not yet be at a stage
when linking a test application works yet, as builtins aren't
available. Therefore set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY,
to avoid failing the compiler sanity check.
Setting CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY has the risk
of making checks for library availability succeed falsely (e.g.
indicating that libs would be available that really aren't, as the
tests don't do any linking), but the builtins library doesn't try to
link against any external libraries (and only produces static libraries
anyway), so it should be safe here.
This avoids having to set CMAKE_C_COMPILER_WORKS when bootstrapping a
cross toolchain, when building the builtins.
Differential Revision: https://reviews.llvm.org/D91334
As reported in D93278 post-review symlinking requires privilege escalation on Windows.
Copying is functionally same, so fallback to it for systems that aren't Unix-like.
This is similar to the solution in AddLLVM.cmake.
Reviewed By: ikudrin
Differential Revision: https://reviews.llvm.org/D98111
On Android, when the builtins are linked into a binary, they are
typically linked using -Wl,--exclude-libs so that the symbols aren't
reexported. For the NDK, compiler-rt's default behavior (build the
builtins archive with -fvisibility=hidden) is better so that builtins
are hidden even without -Wl,--exclude-libs.
Android needs the builtins with non-hidden symbols only for a special
case: for backwards compatibility with old binaries, the libc.so and
libm.so DSOs in the platform need to export some builtins for arm32 and
32-bit x86. See D56977.
Control the behavior with a new flag,
`COMPILER_RT_BUILTINS_HIDE_SYMBOLS`, that behaves similarly to the
`*_HERMETIC_STATIC_LIBRARY` in libunwind/libcxx/libcxxabi, so that
Android can build a special builtins variant for libc.so/libm.so.
Unlike the hermetic flags for other projects, this new flag is enabled
by default.
Reviewed By: compnerd, MaskRay
Differential Revision: https://reviews.llvm.org/D93431
aa772fc85e (D92530) has landed fixing relocations on Darwin.
3000c19df6 (D93236) has landed working around an assembly parser bug on Darwin.
Previous quick-fix d9697c2e6b (D93198) included in this commit.
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Differential Revision: https://reviews.llvm.org/D93278
aa772fc85e (D92530) has landed fixing Apple builds.
Previous quick-fix d9697c2e6b (D93198) included in this commit.
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Differential Revision: https://reviews.llvm.org/D93211
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Reviewed By: ilinpv
Differential Revision: https://reviews.llvm.org/D93178
This patch adds both extendhftf2 and trunctfhf2 to support
conversion between half-precision and quad-precision floating-point
values. They are built iff the compiler supports _Float16.
Some notes on ARM plaforms: while fp16 is supported on all
architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM,
and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also,
fp16 is a storage format and 64-bit ARM supports floating-point
convert precision to half as base armv8-a instruction.
This patch does not change the ABI for 32-bit ARM, it will continue
to pass _Float16 as uint16.
This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726
Differential Revision: https://reviews.llvm.org/D92242
This patch fixes builtins' CMakeLists.txt and their VFP tests to check
the standard macro defined in the ACLE for VFP support. It also enables
the tests to be built and run for single-precision-only targets while
builtins were built with double-precision support.
Differential revision: https://reviews.llvm.org/D92497
On AArch64 it allows use the native FP16 ABI (although libcalls are
not emitted for fptrunc/fpext lowering), while on other architectures
the expected current semantic is preserved (arm for instance).
For testing the _Float16 usage is enabled by architecture base,
currently only for arm, aarch64, and arm64.
This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D92241
Revert "[compiler-rt] [builtins] Support conversion between fp16 and fp128" & dependency
Revert "[compiler-rt] [builtins] Use _Float16 on extendhfsf2, truncdfhf2 __truncsfhf2 if available"
This reverts commit 7a94829881.
This reverts commit 1fb91fcf9c.
This patch adds both extendhftf2 and trunctfhf2 to support
conversion between half-precision and quad-precision floating-point
values. They are enabled iff the compiler supports _Float16.
Some notes on ARM plaforms: while __fp16 is supported on all
architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM,
and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also,
__fp16 is a storage format and promoted to 'float' for argument passing
and 64-bit ARM supports floating-point convert precision to half as
base armv8-a instruction.
It means that although extendhfsf2, truncdfhf2 __truncsfhf2 will be
built for 64-bit ARM, they will be never used in practice (compiler
won't emit libcall to them). This patch does not change the ABI for
32-bit ARM, it will continue to pass _Float16 as uint16.
Differential Revision: https://reviews.llvm.org/D91732
This patch enables building compiler-rt builtins for ARM targets that
only support single-precision floating point instructions (e.g., those
with -mfpu=fpv4-sp-d16).
This fixes PR42838
Differential Revision: https://reviews.llvm.org/D90698
This patch enables support for building compiler-rt builtins for 32-bit
Power arch on AIX. For now, we leave out the specialized ppc builtin
implementations for 128-bit long double and friends since those will
need some special handling for AIX.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D87383
since we will be building both 32-bit and 64-bit compiler-rt builtins
from a single configuration.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D87113
It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86367
D80465 added an assembly implementation of muldi3 for RISC-V but it didn't
add it to the cmake `*_SOURCES` list, so the C implementation was being used
instead. This patch fixes that.
Differential Revision: https://reviews.llvm.org/D86036
long double is a 64-bit double-precision type on:
- MSVC (32- and 64-bit x86)
- Android (32-bit x86)
long double is a 128-bit quad-precision type on x86_64 Android.
The assembly variants of the 80-bit builtins are correct, but some of
the builtins are implemented in C and require that long double be the
80-bit type passed via an x87 register.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D82153
Split filter_builtin_sources into two functions:
- filter_builtin_sources that removes generic files when an
arch-specific file is selected.
- darwin_filter_builtin_sources that implements the EXCLUDE/INCLUDE
lists (using the files in lib/builtins/Darwin-excludes).
darwin_filter_builtin_sources delegates to filter_builtin_sources.
Previously, lib/builtins/CMakeLists.txt had a number of calls to
filter_builtin_sources (with a confusing/broken use of the
`excluded_list` parameter), as well as a redundant arch-vs-generic
filtering for the non-Apple code path at the end of the file. Replace
all of this with a single call to filter_builtin_sources.
Remove i686_SOURCES. Previously, this list contained only the
arch-specific files common to 32-bit and 64-bit x86, which is a strange
set. Normally the ${ARCH}_SOURCES list contains everything needed for
the arch. "i686" isn't in ALL_BUILTIN_SUPPORTED_ARCH.
NFCI, but i686_SOURCES won't be defined, and the order of files in
${arch}_SOURCES lists will change.
Differential Revision: https://reviews.llvm.org/D82151
There are two different _generic_ lists of source files in the compiler-rt/lib/builtins/CMakeLists.txt. Now there is no simple way to not use the tf-variants of helpers at all.
Since there exists a separate `GENERIC_TF_SOURCES` list, it seems quite natural to move all float128-related helpers there. If it is not possible for some reason, it would be useful to have an explanation of that reason somewhere near the `GENERIC_TF_SOURCES` definition.
Differential Revision: https://reviews.llvm.org/D81282
Summary:
This patch implements dynamic stack allocation for the VE target. Changes:
* compiler-rt: `__ve_grow_stack` to request stack allocation on the VE.
* VE: base pointer support, dynamic stack allocation.
Differential Revision: https://reviews.llvm.org/D79084
https://github.com/apple/swift/pull/30112/ makes the Swift standard
library for iOS build for arm64e. If you're building Swift against your
own LLVM, this in turn requires having the builtins built for arm64e,
otherwise you won't be able to use the builtins (which will in turn lead
to an undefined symbol for `__isOSVersionAtLeast`). Make the builtins
build for arm64e to fix this.
Differential Revision: https://reviews.llvm.org/D76041
The configuration for -fPIC in the builtins library when built standalone
is unconditional, stating that the flags would "normally be added... by
the llvm cmake step"
This is untrue, as the llvm cmake step checks LLVM_ENABLE_PIC, which allows
a client to turn off -fPIC.
I've added an option when compiler-rt builtins are configured standalone, such
as when built as part of the LLVM runtimes system, to guard the application of
-fPIC for users that want it.
Patch By: JamesNagurne
Differential Revision: https://reviews.llvm.org/D72950
Implements __fixtfti builtin for PowerPC. This builtin converts a
long double (IBM double-double) to a signed int128. The conversion relies on
the unsigned conversion of the absolute value of the long double.
Tests included for both positive and negative long doubles.
Patch By: Baptiste Saleil
Differential Revision: https://reviews.llvm.org/D69730
Summary:
Previously the CMake code looked for filepaths of the form
`<arch>/<filename>` as an indication that `<arch>/<filename>` provided a
specialization of a top-level file `<filename>`. For powerpc there was a
bug because the powerpc specialized implementations lived in `ppc/` but
the architectures were `powerpc64` and `powerpc64le` which meant that
CMake was looking for files at `powerpc64/<filename>` and
`powerpc64le/<filename>`.
The result of this is that for powerpc the builtins library contained a
duplicate symbol for `divtc3` because it had the generic implementation
and the specialized version in the built static library.
Although we could just add similar code to what there is for arm (i.e.
compute `${_arch}`) to fix this, this is extremely error prone (until
r375150 no error was raised). Instead this patch takes a different
approach that removes looking for the architecture name entirely.
Instead this patch uses the convention that a source file in a
sub-directory might be a specialization of a generic implementation and
if a source file of the same name (ignoring extension) exists at the
top-level then it is the corresponding generic implementation. This
approach is much simpler because it doesn't require keeping track of
different architecture names.
This convention already existed in repository but previously it was
implicit. This change makes it explicit.
This patch is motivated by wanting to revert r375162 which worked around
the powerpc bug found when r375150 landed.
Once it lands we should revert r375162.
Reviewers: phosek, beanz, compnerd, shiva0217, amyk, rupprecht, kongyi, mstorsjo, t.p.northover, weimingz, jroelofs, joerg, sidneym
Subscribers: nemanjai, mgorny, kristof.beyls, jsji, shchenz, steven.zhang, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D69189
compiler-rt's builtin library has generic implementations of many
functions, and then per-arch optimized implementations of some.
In the CMake build, both filter_builtin_sources() and an explicit loop
at the end of the build file (see D37166) filter out the generic
versions if a per-arch file is present.
The GN build wasn't doing this filtering. Just do the filtering manually
and explicitly, instead of being clever.
While here, also remove files from the mingw/arm build that are
redundantly listed after D39938 / r318139 (both from the CMake and the
GN build).
While here, also fix a target_os -> target_cpu typo.
Differential Revision: https://reviews.llvm.org/D65512
llvm-svn: 367448
This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward:
- Add 32 and 64-bit sparc to compiler-rt
- lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc)
There's one issue of note: many asan tests fail to compile on Solaris/SPARC:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The
goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc,
which doesn't have the problem above and works just fine.
With this patch, sparcv9-sun-solaris2.11 test results are pretty good:
Failing Tests (9):
Builtins-sparc-sunos :: divtc3_test.c
Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
Builtins-sparcv9-sunos :: divtc3_test.c
[...]
UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp
UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp
The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal
patches either currently in review or about to be submitted.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D40943
llvm-svn: 365880
compiler-rt already uses libtool instead of ar when building for
Apple platform, but that's not being used when builtins are being
built separately e.g. as part of the runtimes build. This change
extracts the logic setting up libtool into a separate file and uses
it from both the compiler-rt and standalone builtins build.
Differential Revision: https://reviews.llvm.org/D62820
llvm-svn: 362466
Raul Tambre