After this patch, the softfp implementations of floatdidf and floatundidf
use a common implementation (int_to_fp.h and int_to_fp_impl.inc). This
roughly follows the pattern used for a wide range of other builtins,
e.g. fp_trunc_impl.inc.
Currently there is substantial copy and paste for the various int to fp
conversion functions, with just a few constants being changed. This is a
barrier to maintainability, and it's also not attractive to copy this
approach as we introduce additional int to fp conversion functions for
bf16 and half (which we currently lack, but need - see
<https://reviews.llvm.org/D157509>).
I've opted to conservatively start by replacing just two functions,
leaving a follow-up patch to replace others that follow the same
pattern. Also, for better or worse I've left the logic in float[un]didf
largely unchanged other than using a similar approach to
fp_trunc_impl.inc to remove the constants that are tied to a specific
output floating point format.
When compiling compiler-rt with -fsanitize=undefined and running testcases you
end up with the following warning:
UBSan: floatdisf.c:27:15: signed integer overflow: 9223372036854775807 - -1 cannot be represented in type 'di_int' (aka 'long long')
This can be avoided by doing the subtraction in a matching unsigned variant of
the type, given that the overflow is the expected result of the subtraction.
The same kind of pattern exists in floatdidf.c
This was found in an out of tree target.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D146135
This avoids pulling in all of them if only one of them is needed
(if builtins are built without -ffunction-sections), and matches how
the similar aliases for AEABI are set up.
Differential Revision: https://reviews.llvm.org/D107815
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
Symbol aliases are supported by all platforms that compiler-rt builtins
target, and we can use these instead of function redirects to avoid the
extra indirection.
This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".
Differential Revision: https://reviews.llvm.org/D60931
llvm-svn: 359413
Use the uniform single line C++/99 style for code comments.
This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".
Differential Revision: https://reviews.llvm.org/D60352
llvm-svn: 359411
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
r303188 removed all the uses of aliases for EABI functions from
compiler-rt, because some of them had mismatched calling conventions.
Obviously, we can't use aliases for functions which don't have the same
calling convention, but that's only an issue for floating-point
functions with the hardfloat ABI. In other cases, the stubs increase
size and reduce performance for no benefit.
This patch adds back the aliases, with appropriate checks to make sure
they're only used in cases where the calling convention matches.
llvm-svn: 314851
These actually may change calling conventions. We cannot simply provide
function aliases as the aliased function may have a different calling
convention. Provide a forwarding function instead to permit the
compiler to synthesize the calling convention adjustment thunk.
Remove the `ARM_EABI_FNALIAS` macro as that is not safe to use.
Resolves PR33030!
llvm-svn: 303188
MSVC 2013 doesnt support C99 fully, including the hexidecimal floating point
representation. Use the expanded value to permit building with it.
Patch by Tee Hao Wei!
llvm-svn: 250365
