#56854 shows a backwards compatibility problem when builtins of compiler-rt don't follow ABI. We need to prevent to fall into the trap again for BF16.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D131147
Instead of detecting `_Float16` support at CMake configuration time,
detect it at compile time by checking for the predefined (by the
compiler) macro `__FLT16_MAX__` instead.
This solves the issue where compiler-rt is built simultaneously for both
x86_64 and i386 targets, and the CMake configuration uses x86_64
compilation to detect `_Float16` support, while it may not be supported
by the i386 target (if it does not have SSE2).
While here, rename `COMPILERT_RT_HAS_FLOAT16` to `CRT_HAS_FLOAT16`, to
conform more to the naming style used in `int_lib.h` and `int_types.h`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D130718
This is modeled after the half-precision fp support. Two new nodes are
introduced for casting from and to bf16. Since casting from bf16 is a
simple operation I opted to always directly lower it to integer
arithmetic. The other way round is more complicated if you want to
preserve IEEE semantics, so it's handled by a new __truncsfbf2
compiler-rt builtin.
This is of course very bare bones, but sufficient to get a semi-softened
fadd on x86.
Possible future improvements:
- Targets with bf16 conversion instructions can now make fp_to_bf16 legal
- The software conversion to bf16 can be replaced by a trivial
implementation under fast math.
Differential Revision: https://reviews.llvm.org/D126953
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.
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).
Differential Revision: https://reviews.llvm.org/D91733
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
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
__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
Mostly uninteresting, except:
- in __extendXfYf2, when checking if the number is normal, the old
code relied on the unsignedness of src_rep_t, which is a problem
when sizeof(src_rep_t) < sizeof(int): the result gets promoted to
int, the signedness of which breaks the comparison.
I added an explicit cast; it shouldn't affect other types.
- we can't pass __fp16, so src_t and src_rep_t are the same.
- the gnu_*_ieee symbols are simply duplicated definitions, as aliases
are problematic on mach-o (where only weak aliases are supported;
that's not what we want).
Differential Revision: http://reviews.llvm.org/D9693
llvm-svn: 237161
Phoebe Wang