This fixes:
```
[3334/7449] Building C object projects\compiler-rt\lib\builtins\CMakeFiles\clang_rt.builtins-x86_64.dir\extendsfdf2.c.obj
C:\git\llvm-project\compiler-rt\lib\builtins\fp_extend_impl.inc(63): warning C4018: '<': signed/unsigned mismatch
```
This variable was explicitly removed from the cache to ease transition
from existing build directories but that breaks passing
COMPILER_RT_BUILD_CRT=OFF on the command line. I was surprised to see
the CRT builds being run for my builtins-only build config (I noticed
because one of the tests was failing despite having `REQUIRES: crt`).
If I pass `-DCOMPILER_RT_BUILD_CRT=OFF` to cmake and add some prints
around the `unset` statement it shows the following:
```
-- before unset(): COMPILER_RT_BUILD_CRT=OFF
-- after unset: COMPILER_RT_BUILD_CRT=
-- after cmake_dependent_option COMPILER_RT_BUILD_CRT=ON
```
Drop this temporary workaround now that over 6 months have passed.
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>
After 05a4212cc76d a number of long double related declarations are
enabled in `int_types.h`, whenever the CPU architecture and platform
support it. However, this does not work with FreeBSD's standalone
environment, which disallows any use of floating point.
In add98b246290 this was made conditional with `CRT_HAS_FLOATING_POINT`,
so extend the block guarded by that define to include all floating point
related declarations.
a15532d7647a8a4b7fd2889bd97f6f72f273c4bf landed a patch that added
support for detecting more AMD znver2 CPUs and cleaned up some of the
surrounding code, including the znver3 detection. Since one model group
is 00h-0fh, I adjusted the check to include checking if the value is
greater than zero. Since the value is unsigned, this is always true and
gcc warns on it. This patch removes the comparison with zero to get rid
of the compiler warning.
[builtins] Fix CPU feature detection for FreeBSD on AArch64
This is a follow-up to #75635 which broke the build for FreeBSD on
AArch64:
```
compiler-rt/lib/builtins/cpu_model/aarch64/lse_atomics/freebsd.inc:3:16: error: call to undeclared function 'elf_aux_info'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
3 | int result = elf_aux_info(AT_HWCAP, &hwcap, sizeof hwcap);
| ^
```
Using `elf_aux_info()` requires including `<sys/auxv.h>` first. To
prevent redeclaration issues with `hwcap.inc` attempting to define
`HWCAP_xxx` macros before `<sys/auxv.h>` does so, include `<sys/auxv.h>`
before any of the `.inc` files on FreeBSD.
This is a follow up to #75635 which broke the build on Fuchsia. We don't
support ifunc on Fuchsia so we shouldn't define __init_cpu_features. For
__init_cpu_features_resolver we have to use _zx_system_get_features as a
Zircon native solution.
This patch adds proper detection support for more znver2 CPUs.
Specifically, this adds in support for CPUs codenamed Renoir, Lucienne,
and Mendocino.
This was originally proposedfor Renoir in
https://reviews.llvm.org/D96220 and
got approved, but slipped through the cracks. However, there is still a
demand for this feature.
In addition to adding support for more znver2 CPUs, this patch also includes
some additional refactoring and comments related to cpu model
information for zen CPUs.
Fixes https://github.com/llvm/llvm-project/issues/74934.
And its follow up "fixup! [builtins][arm64] Build __init_cpu_features_resolver on Apple platforms (#73685)".
This reverts commit 5b470522cdd6af3796c05ecd7d979a74f9cb43a8 and
212a5e1b9c9221d10bc35cbbbb7123ddffef47e4.
Due to build failures on Windows:
```
C:\Users\Tcwg\llvm-worker\clang-arm64-windows-msvc-2stage\llvm\compiler-rt\lib\builtins\cpu_model.c(1571,2): error: No support for checking hwcap on this platform yet.
1571 | #error No support for checking hwcap on this platform yet.
| ^
```
https://lab.llvm.org/buildbot/#/builders/120/builds/5990
Whenever linking with -nodefaultlibs for a MinGW target, we manually
need to specify a bunch of libraries - listed in ${MINGW_LIBRARIES}; the
same is already done for sanitizers and libunwind/libcxxabi/libcxx.
Practically speaking, linking with -nodefaultlibs but manually passing
the libraries in ${MINGW_LIBRARIES} restores most of the libraries that
are linked by default, except for the potential compiler builtins and
unwind library; i.e. it has essentially the same effect as linking with
"--unwindlib=none -rtlib=none", except that -rtlib doesn't accept such a
value.
When building only compiler-rt/lib/builtins, not all of compiler-rt,
${MINGW_LIBRARIES} is unset - set it manually here for that case. This
matches what is set in
compiler-rt/cmake/config-ix.cmake, except that the builtins (libgcc or
compiler-rt builtins) is omitted; the only use within lib/buitlins is
for the standalone libatomic, which explicitly already links against the
just-built builtins.
GCC is able to check that the signatures of the builtins are as expected
and this shows some incorrect signatures on ld80 platforms (i.e. x86).
The *tf* functions should take 128-bit arguments but until the latest fixes
they used 80-bit long double.
Differential Revision: https://reviews.llvm.org/D153814
compiler-rt/builtins doesn't depend on anything from the CRT but
currently links against it and embeds a `/defaultlib:msvcrt` in the
`.lib` file, forcing anyone linking against it to also link against that
specific CRT. This isn't necessary as the end user can just choose which
CRT they want to use independently.
This is a follow-up to 910a4bf5b.
1. __builtin_clz takes unsigned int, thus for uint16_t
src_rep_t_clz can't use it directly but should subtract 16
(leading 16 bits of the promoted argument are zero).
2. Fix (and simplify) clz_in_sig_frac.
Test plan: ninja check-compiler-rt
(extendhfsf2_test.c and extenddftf2_test.c)
Use of long double can be error-prone since it could be one of 80-bit
extended precision float, IEEE 128-bit float, or IBM 128-bit float.
Instead use an explicit xf_float typedef for the remaining cases where
long double is being used in the implementation. This patch does not
touch
the PPC specializations which still use long double.
69660ccf2ae402b02799efed072afd8ecf5a6eb0 broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/staging/#/builders/12/builds/264):
`compiler-rt/lib/builtins/int_to_fp.h` unconditionally uses `*int128_t`
which don't exist on 32-bit SPARC.
As suggested in https://github.com/llvm/llvm-project/pull/67540, this
patch fixes this by moving the `CRT_HAS_TF_MODE` guard up which does the
necessary checks.
Tested on `sparcv9-sun-solaris2.11`.
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.
This patch fixes:
compiler-rt/lib/builtins/int_to_fp_impl.inc:22:18: error: expression
is not an integer constant expression; folding it to a constant is a
GNU extension [-Werror,-Wgnu-folding-constant]
by using enum for constants.
This patch fixes:
compiler-rt/lib/builtins/cpu_model.c:590:5: error: unannotated
fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
by adding a missing "break;".
This patch fixes:
compiler-rt/lib/builtins/int_to_fp_impl.inc:36:10: error: expression
is not an integer constant expression; folding it to a constant is a
GNU extension [-Werror,-Wgnu-folding-constant]
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.
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.
Resolved issue with green dragon build by fixing relocations for
MachO/Darwin which doesn't compile without @page/@pageoff directives.
Also silenced a warning about constructor(90) priority being < 101,
which is reserved for the implementation. In this case, we're compiling
the implementation so we should be able to use 90.
This reverts commit 072713add4408199d4bce7b3b02cc74a4a382ee0.
