This patch implements __extendxftf2 (long double -> f128) and
__trunctfxf2 (f128 -> long double) on x86_64.
This is a preparation to unblock https://reviews.llvm.org/D53608,
We intentionally do not modify compiler-rt/lib/builtins/fp_lib.h in this
PR
(in particular, to limit the scope and avoid exposing other functions on
X86_64 in this PR).
Instead, TODOs were added to use fp_lib.h once it is available.
Test plan:
1. ninja check-compiler-rt (verified on X86_64 and on Aarch64)
In particular, new tests (extendxftf2_test.c and trunctfxf2_test.c) were
added.
2. compared the results of conversions with what other compilers (gcc)
produce.
Invoking compiler-rt function __truncsfbf2 to convert a zero 32-bit float
0x00000000 to a 16-bit bfloat value currently generates the denormal value
0x0040, rather than value 0x0000. Negative zero 0x80000000 is converted
to denormal 0x8040 rather than 0x8000.
This behavior is seen in flang code under development (not yet integrated)
that converts bfloat/REAL(KIND=3) argument values to float/REAL(KIND=4)
values and then converts those values back to bfloat/REAL(KIND=3). There
are other instances of the problem. A round-trip type conversion using
__truncsfbf2 of a denormal generates a different denormal, and an sNaN
is converted to a qNaN.
The problem is addressed in generic conversion function fp_trunc_impl.inc
by removing trailing 0 significand bits when the source and destination
type formats are identical except for the significand size. This condition
is met only for float -> bfloat conversions.
Round-trip conversions for at least some other type pairs have the same
problem. A solution in those cases would need to account for exponent
size differences. Those cases are not relevant to flang compilations
and are not addressed here. A broader solution might subsume this fix,
or this fix might remain useful as is.
There are no existing tests of bfloat conversion functionality in the
compiler-rt test directory. Tests for other conversions use a common
infrastructure that does not currently have support for bfloat conversions.
This patch does not attempt to add that infrastructure for this new case.
CodeGen test bfloat.ll checks bfloat adds and other operations that invoke
__truncsfbf2.
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
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
Summary:
This patch fixes incorrect truncation when the input wider value is
exactly 2^dstBits. For that value, the overflow to infinity is not
correctly handled. The fix is to replace a strict '>' with '>='.
Currently,
__truncdfsf2(340282366900000000000000000000000000000.0) returns infinity
__truncdfsf2(340282366920938463463374607431768211456.0) returns 0
__truncdfsf2(400000000000000000000000000000000000000.0) returns infinity
Likewise, __truncdfhf2 and __truncsfhf2 (and consequently gnu_f2h_ieee)
are discontinuous at 65536.0.
This patch adds tests for all three cases, along with adding a missing
header include to fp_test.h.
Reviewers: joerg, ab, srhines
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10594
llvm-svn: 240450
