[compiler-rt] Add missing carry to 128x128->256 wide multiply (#97257)

[compiler-rt][builtins]Adjust complex division for aarch64 (#106664)

Adjust __divsc3 to ensure consistent behavior across x86_64 and AArch64 when the divisor should be treated as infinity if one of

[compiler-rt][builtins]Adjust complex division for aarch64 (#106664)

Adjust __divsc3 to ensure consistent behavior across x86_64 and AArch64 when the divisor should be treated as infinity if one of its components is a NaN (including signaling NaNs).

Test plan: ninja check-all

show more ...

[builtins] Use __builtin_clzll for 64-bit types (#99874)

This addresses the issue with `__LP64__` not being defined for targets
with 32-bit pointers but 64-bit longs, resulting in worse codegen.

compiler-rt: fix few builtins build warnings. (#88991)

Unbreak *tf builtins for hexfloat (#82208)

This re-lands cc0065a7d082f0bd322a538cf62cfaef1c8f89f8 in a way that
keeps existing targets working.

---------

Original commit message:
#68132 end

Unbreak *tf builtins for hexfloat (#82208)

This re-lands cc0065a7d082f0bd322a538cf62cfaef1c8f89f8 in a way that
keeps existing targets working.

---------

Original commit message:
#68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support.
I added support for QUAD_PRECISION to use the native hex float long double representation.

---------

Co-authored-by: Sean Perry <perry@ca.ibm.com>

show more ...

Revert "[builtins] Generate __multc3 for z/OS" (#77881)

Reverts llvm/llvm-project#77554 because of #77880

[builtins] Generate __multc3 for z/OS (#77554)

https://github.com/llvm/llvm-project/pull/68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but no

[builtins] Generate __multc3 for z/OS (#77554)

https://github.com/llvm/llvm-project/pull/68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support. I added support for QUAD_PRECISION to
use the native hex float long double representation.

---------

Co-authored-by: Alexander Richardson <mail@alexrichardson.me>

show more ...

[compiler-rt] Remove a few workarounds for FreeBSD 9.x (#76263)

Support for FreeBSD 11.x was dropped so garbage collect a few FreeBSD
9.x workarounds and make 12.x the oldest supported releases.

[builtins] Support building the 128-bit float functions on ld80 platforms (#68132)

GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64.
Since Clang supports float128, we can also

[builtins] Support building the 128-bit float functions on ld80 platforms (#68132)

GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64.
Since Clang supports float128, we can also enable the existing code by
using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is
defined instead of only supporting these builtins for platforms with
128-bit IEEE long doubles.
This commit defines a new tf_float typedef that matches a float with
attribute((mode(TF)) on each given architecture.

There are more tests that could be enabled for x86, but to keep the diff
smaller, I restricted test changes to ones that started failing as part
of this refactoring.

This change has been tested on x86 (natively) and
aarch64,powerpc64,riscv64 and sparc64 via qemu-user.

This supersedes https://reviews.llvm.org/D98261 and should also cover
the changes from https://github.com/llvm/llvm-project/pull/68041.

show more ...

[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC

Currently the *tf builtin functions can only be built if long double is an
IEEE float, which prevents them from being available e.g. for

[builtins] Avoid using CRT_LDBL_128BIT in implementation. NFC

Currently the *tf builtin functions can only be built if long double is an
IEEE float, which prevents them from being available e.g. for x86 targets
(unlike libgcc which has them). This non-functional change prepares the
builtins library *tf functions for being able to target x86 by decoupling
their presence from CRT_LDBL_128BIT and instead checking for a
CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is
currently only set if long double is an IEEE 128-bit float.

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D153812

show more ...

[builtins] Avoid using floating point q suffix. NFCI

The q floating point suffix is not supported by all compilers
configurations (e.g. GCC only supports it for some targets), so use a
macro (much l

[builtins] Avoid using floating point q suffix. NFCI

The q floating point suffix is not supported by all compilers
configurations (e.g. GCC only supports it for some targets), so use a
macro (much like UINT64_C) instead. As this touches almost all lines in
the two tests also run them through clang-format.

show more ...

[builtins] Fix __floattitf and __floatuntitf on x86

These conversion functions were using LDBL_MANT_DIG (which is the 80-bit
extended float on x86) instead of the appropriate macro for the 128-bit
f

[builtins] Fix __floattitf and __floatuntitf on x86

These conversion functions were using LDBL_MANT_DIG (which is the 80-bit
extended float on x86) instead of the appropriate macro for the 128-bit
floating point type expected by the *tf* softfloat library calls.
This was discovered while testing D98261 (which allows building the *tf*
functions on x86).

This also changes the constants used in the two tests to use 128-bit
floating-point literals instead of long double ones to ensure that the
comparison succeeds on platforms with smaller long double (e.g. x86_64)

Reviewed By: scanon

Differential Revision: https://reviews.llvm.org/D131787

show more ...

Reland "[builtins] Define fmax and scalbn inline"

This reverts commit 680f836c2fa72166badd594a52b3f41b2ad074d2.

Disable the non-default-rounding-mode scalbn[f] tests when we're using
the MSVC libra

Reland "[builtins] Define fmax and scalbn inline"

This reverts commit 680f836c2fa72166badd594a52b3f41b2ad074d2.

Disable the non-default-rounding-mode scalbn[f] tests when we're using
the MSVC libraries.

Differential Revision: https://reviews.llvm.org/D91841

show more ...

Revert "[builtins] Define fmax and scalbn inline"

This reverts commit 341889ee9e03e73b313263c516b3d1fd33d4c4ba.

The new unit tests fail on sanitizer-windows.

[builtins] Define fmax and scalbn inline

Define inline versions of __compiler_rt_fmax* and __compiler_rt_scalbn*
rather than depend on the versions in libm. As with
__compiler_rt_logbn*, these funct

[builtins] Define fmax and scalbn inline

Define inline versions of __compiler_rt_fmax* and __compiler_rt_scalbn*
rather than depend on the versions in libm. As with
__compiler_rt_logbn*, these functions are only defined for single,
double, and quad precision (binary128).

Fixes PR32279 for targets using only these FP formats (e.g. Android
on arm/arm64/x86/x86_64).

For single and double precision, on AArch64, use __builtin_fmax[f]
instead of the new inline function, because the builtin expands to the
AArch64 fmaxnm instruction.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D91841

show more ...

[builtins] Unify the softfloat division implementation

This patch replaces three different pre-existing implementations of
__div[sdt]f3 LibCalls with a generic one - like it is already done for
many

[builtins] Unify the softfloat division implementation

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

show more ...

[builtins] Improve compatibility with 16 bit targets

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 Undef

[builtins] Improve compatibility with 16 bit targets

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

show more ...

[builtins] Support architectures with 16-bit int

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

[builtins] Support architectures with 16-bit int

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

show more ...

Fix int to bool errors exposed due to r372612.

Differential Revision: https://reviews.llvm.org/D67937
M lib/builtins/fp_add_impl.inc
M lib/builtins/fp_lib.h
M lib/builtins/fp_trunc_impl.i

Fix int to bool errors exposed due to r372612.

Differential Revision: https://reviews.llvm.org/D67937
M lib/builtins/fp_add_impl.inc
M lib/builtins/fp_lib.h
M lib/builtins/fp_trunc_impl.inc

llvm-svn: 372684

show more ...

Enable compiler-rt on SPARC

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 che

Enable compiler-rt on SPARC

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

show more ...

[builtins] Reformat builtins with clang-format

Update formatting to use the LLVM style.

This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".

Differential R

[builtins] Reformat builtins with clang-format

Update formatting to use the LLVM style.

This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".

Differential Revision: https://reviews.llvm.org/D60351

llvm-svn: 359410

show more ...

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648

show more ...

[compiler-rt] [builtins] Add logb/logbf/logbl methods to compiler-rt to avoid libm dependencies when possible.

Summary:
The complex division builtins (div?c3) use logb methods from libm to scale num

[compiler-rt] [builtins] Add logb/logbf/logbl methods to compiler-rt to avoid libm dependencies when possible.

Summary:
The complex division builtins (div?c3) use logb methods from libm to scale numbers during division and avoid rounding issues. However, these come from libm, meaning anyone that uses --rtlib=compiler-rt also has to include -lm. Implement logb* methods for standard ieee 754 floats so we can avoid -lm on those platforms, falling back to the old behavior (using either logb() or `__builtin_logb()`) when not supported.

These new methods are defined internally as `__compiler_rt_logb` so as not to conflict with the libm definitions in any way.

This fixes just the libm methods mentioned in PR32279 and PR28652. libc is still required, although that seems to not be an issue.

Note: this is proposed as an alternative to just adding -lm: D49330.

Reviewers: efriedma, compnerd, scanon, echristo

Reviewed By: echristo

Subscribers: jsji, echristo, nemanjai, dberris, mgorny, kbarton, delcypher, llvm-commits, #sanitizers

Differential Revision: https://reviews.llvm.org/D49514

llvm-svn: 342917

show more ...

builtins: spell inline as __inline

__inline is a vendor specific spelling for inline. clang and gcc treat it the
same as inline, and is available in MSVC 2013 which does not implement C99
(VS2015 s

builtins: spell inline as __inline

__inline is a vendor specific spelling for inline. clang and gcc treat it the
same as inline, and is available in MSVC 2013 which does not implement C99
(VS2015 supports the inline keyword though). This will allow us to build the
builtins using MSVC.

llvm-svn: 249953

show more ...

Support building floating-point facilities on FreeBSD 9.2 in 32-bit mode
Differential Revision: http://reviews.llvm.org/D3909

llvm-svn: 212518