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
Implements `__clear_cache` for RISC-V Linux. We can't just use `fence.i` on
Linux, because the Linux thread might be scheduled on another hart, and the
`fence.i` instruction only flushes the icache of the current hart.
Summary:
For builtin compiler-rt, it is built with visibility hidden by default
to avoid the client exporting symbols from libclang static library. The
compiler option -fvisibility=hidden doesn't work on the aliases in c files
because they are created with inline assembly. On Darwin platform,
thoses aliases are exported by default if they are reference by the client.
Fix the issue by adding ".private_extern" to all the aliases if the
library is built with visibility hidden.
rdar://problem/58960296
Reviewers: dexonsmith, arphaman, delcypher, kledzik
Reviewed By: delcypher
Subscribers: dberris, jkorous, ributzka, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D73577
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
Darwin lazily saves the AVX512 context on first use [1]: instead of checking
that it already does to figure out if the OS supports AVX512, trust that
the kernel will do the right thing and always assume the context save
support is available.
[1] https://github.com/apple/darwin-xnu/blob/xnu-4903.221.2/osfmk/i386/fpu.c#L174
Reviewers: ab, RKSimon, craig.topper
Reviewed By: craig.topper
Subscribers: dberris, JDevlieghere, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D70454
Anatoly Trosinenko