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
The code currently uses __c11_atomic_is_lock_free() to detect whether an
atomic operation is natively supported. However, this can result in a
runtime function call to determine whether the given operation is lock-free
and clang generating a call to e.g. __atomic_load_8 since the branch is
not a constant zero. Since we are implementing those runtime functions, we
must avoid those calls. This patch replaces __c11_atomic_is_lock_free()
with __atomic_always_lock_free() which always results in a compile-time
constant value. This problem was found while compiling atomic.c for MIPS32
since the -Watomic-alignment warning was being triggered and objdump showed
an undefined reference to _atomic_is_lock_free.
In addition to fixing 32-bit platforms this also enables the 16-byte case
that was disabled in r153779 (185f2edd70).
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D86510
Add the implementation of __isOSVersionAtLeast for Android. Currently,
only the major version is checked against the API level of the platform
which is an integer. The API level is retrieved by reading the system
property ro.build.version.sdk (and optionally ro.build.version.codename
to see if the platform is released or not).
Patch by jiyong@google.com
Bug: 150860940
Bug: 134795810
Test: m
Reviewed By: srhines
Differential Revision: https://reviews.llvm.org/D86596
Previously we calculating the remainder by multiplying the
quotient and divisor and subtracting from the dividend.
__udivmod can calculate the remainder while calculating the
quotient. We just need to correct the sign afterward.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D87433
No point in making __parityti2 go through 2 calls to get to
__paritysi2.
Reviewed By: MaskRay, efriedma
Differential Revision: https://reviews.llvm.org/D87218
This patch introduces denormal result support to soft-float division
implementation unified by D85031.
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D85032
This patch replaces three different pre-existing implementations of
__div[sdt]f3 LibCalls with a generic one - like it is already done for
many other LibCalls.
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D85031
The existing implementations are almost identical except for width of the
integer type.
Factor them out to int_mulo_impl.inc for better maintainability.
This patch is almost identical to D86277.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86289
The existing implementations are almost identical except for width of the
integer type.
Factor them out to int_mulv_impl.inc for better maintainability.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86277
Support -march=sapphirerapids for x86.
Compare with Icelake Server, it includes 14 more new features. They are
amxtile, amxint8, amxbf16, avx512bf16, avx512vp2intersect, cldemote,
enqcmd, movdir64b, movdiri, ptwrite, serialize, shstk, tsxldtrk, waitpkg.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D86503
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
Instead of ANDing with a one hot mask representing the bit to
be tested, we were ANDing with just the bit number. This tests
multiple bits none of them the correct one.
This caused skylake-avx512, cascadelake and cooperlake to all
be misdetected. Based on experiments with the Intel SDE, it seems
that all of these CPUs are being detected as being cooperlake.
This is bad since its the newest CPU of the 3.
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
Android 32-bit x86 uses a 64-bit long double.
Android 64-bit x86 uses a 128-bit quad-precision long double.
Differential Revision: https://reviews.llvm.org/D82152
These aren't used in compiler-rt, but I plan to make a similar
change to the equivalent code in Host.cpp where the mapping from
type/subtype is an unnecessary complication. Having the CPU strings
here will help keep the code somewhat synchronized.
This patch changes types of some integer function arguments or return values from `si_int` to the default `int` type to make it more compatible with `libgcc`.
The compiler-rt/lib/builtins/README.txt has a link to the [libgcc specification](http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc). This specification has an explicit note on `int`, `float` and other such types being just illustrations in some cases while the actual types are expressed with machine modes.
Such usage of always-32-bit-wide integer type may lead to issues on 16-bit platforms such as MSP430. Provided [libgcc2.h](https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcc2.h;hb=HEAD) can be used as a reference for all targets supported by the libgcc, this patch fixes some existing differences in helper declarations.
This patch is expected to not change behavior at all for targets with 32-bit `int` type.
Differential Revision: https://reviews.llvm.org/D81285
Some parts of existing codebase assume the default `int` type to be (at least) 32 bit wide. On 16 bit targets such as MSP430 this may cause Undefined Behavior or results being defined but incorrect.
Differential Revision: https://reviews.llvm.org/D81408
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
We need to set the cpu_vendor to a non-zero value to indicate
that we already called __cpu_indicator_init once.
This should only happen on a 386 or 486 CPU.
Summary: we use the alias attribute, similar to what is done for ELF.
Reviewers: ZarkoCA, jasonliu, hubert.reinterpretcast, sfertile
Reviewed By: jasonliu
Subscribers: dberris, aheejin, mstorsjo, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D81120
Brand index was a feature some Pentium III and Pentium 4 CPUs.
It provided an index into a software lookup table to provide a
brand name for the CPU. This is separate from the family/model.
It's unclear to me why this index being non-zero was used to
block checking family/model. None of the CPUs that had a non-zero
brand index are supported by __builtin_cpu_is or target
multi-versioning so this should have no real effect.
Provides an assembly implementation of muldi3 for RISC-V, to solve bug 43388.
Since the implementation is the same as for mulsi3, that code was moved to
`riscv/int_mul_impl.inc` and is now reused by both `mulsi3.S` and `muldi3.S`.
Differential Revision: https://reviews.llvm.org/D80465
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
This adds the family/model returned by CPUID for some Intel
Comet Lake CPUs. Instruction set and tuning wise these are
the same as "skylake".
These are not in the Intel SDM yet, but these should be correct.
Summary:
Synchronize the function definition with the LLVM documentation.
https://llvm.org/docs/Atomics.html#libcalls-atomic
GCC also returns bool for the same atomic builtin.
Reviewers: theraven
Reviewed By: theraven
Subscribers: theraven, dberris, jfb, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79845
This is the first patch in a series to add support for the AVR target.
This patch includes changes to make compiler-rt more target independent
by not relying on the width of an int or long.
Differential Revision: https://reviews.llvm.org/D78662
The following declarations were missing a prototype:
FE_ROUND_MODE __fe_getround();
int __fe_raise_inexact();
Discovered while fixing a bug in Clang related to unprototyped function
calls (see the previous commit).
Differential Revision: https://reviews.llvm.org/D78205
@kamleshbhalui reported that when the Standard Extension M
(Multiplication and Division) is disabled for RISC-V,
`__udivdi3` will call __udivmodti4 which will in turn calls `__udivdi3`.
This patch moves __udivsi3 (shift and subtract) to int_div_impl.inc
`__udivXi3`, optimize a bit, add a `__umodXi3`, and use `__udivXi3` and
`__umodXi3` to define `__udivsi3` `__umodsi3` `__udivdi3` `__umoddi3`.
Reviewed By: kamleshbhalui
Differential Revision: https://reviews.llvm.org/D77912
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
David Tenty