This patch adds two new macros to setjmp (STORE, STORE_FP) and two new
macros to longjmp (LOAD, LOAD_FP) that takes a register and a buff, then
select the correct asm instruction for rv32 and rv64.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D158640
This patch changes the instruction in set_thread_ptr from ld to mv,
as rv32 doesn't have the ld instruction, and mv is supported by both
rv32 and rv64.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D159110
This patch changes a test case that tests for overflow when time_t is
32-bit long, however, it was checking size_t instead of time_t.
This in on par with other testcases that correctly check the size of
time_t (asctime_test.cpp, gmtime_r_test.cpp and gmtime_test.cpp).
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D159113
Currently all of this logic expects to include and link with the headers
in the `linux/` directory. This patch adds a wrapper macro to optionally
add the appropriate dependency if it exists. This is preliminary to
adding some GPU specific versions of these files.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D159021
This patch adds some extra cases to the existing argument list test in
`libc`, mainly dealing with arguments of varying sizes and primitive
types.
The purpose of this patch is to provide a wider test area when we begin
to provide varargs support on the GPU as there is no other runtime code
that really tests it. So, running these tests more exhaustively in the
GPU libc project will serve as the runtime tests for GPU vararg support in
D158246.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D158867
Implement double precision exp2 function correctly rounded for all
rounding modes. Using the same algorithm as double precision exp function in
https://reviews.llvm.org/D158551.
Reviewed By: zimmermann6
Differential Revision: https://reviews.llvm.org/D158812
Implement double precision exp function correctly rounded for all
rounding modes. Using 4 stages:
- Range reduction: reduce to `exp(x) = 2^hi * 2^mid1 * 2^mid2 * exp(lo)`.
- Use 64 + 64 LUT for 2^mid1 and 2^mid2, and use cubic Taylor polynomial to
approximate `(exp(lo) - 1) / lo` in double precision. Relative error in this
step is bounded by 1.5 * 2^-63.
- If the rounding test fails, use degree-6 Taylor polynomial to approximate
`exp(lo)` in double-double precision. Relative error in this step is bounded by
2^-99.
- If the rounding test still fails, use degree-7 Taylor polynomial to compute
`exp(lo)` in ~128-bit precision.
Reviewed By: zimmermann6
Differential Revision: https://reviews.llvm.org/D158551
This `MAX_LANE_SIZE` was a hack from the days when we used a single
instance of the server and had some GPU state handle it. Now that we
have everything templated this really shouldn't be used. This patch
removes its use and replaces it with template arguments.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D158633
The `atexit` function depends on the implementations in CPP/new.h but it
is not listed as a dependency. This causes the GPU build to not include
it in the `libcgpu.a` file and prevents us from using the startup code
externally. Simply add it.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D158447
We previously provided the `try_open` facility to indicate if opening a
port failed. This is used on the server to continuously poll and quit if
there is no work. However the Client currently has no way to recover
from not finding a port and simply spins repeatedly. The abstraction
here costs us some resources. This patch changes the interface to only
allow `open` on the client side and merges the loops. This saves us a
branch and a good number of registers.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D158365
The fuzzer found that a 100,000 digit number could possibly return an
incorrect result. This patch fixes the issue.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D158118
We currently remap vendor implementations of math functions to provide a
temporarily functional `libm.a` for the GPU. However, we should not run
tests on any files that depend on these vendor implementations as they
are not under our control and are not always present.
The goal in the future is to remove the need for this by replacing all
the vendor functionality, but for now this is a workaround.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D158213
We use `find_program` to identify a few programs we use for offloading.
Namely, `clang-offload-packger`, `amdgpu-arch`, and `nvptx-arch`.
Currently the logic allows these to bind to any tool matching this name,
so it will find it on the system. This meant that if the installation
was deleted or it found a broken binary the compilation would fail. We
should only pull these from the current LLVM binary directory.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D158203
This patch moves the storage from inside the libc's optional class to
its own set of class, so we can support non-trivially destructible
objects.
These new classes check if the class is or isn't non trivially
destructible and instantiate the correct base class, i.e., we explicitly
call the destructor if an object is not trivially destructible.
The motivation is to support cpp::optional<UInt<128>> (used by
UInt<T>::div), which is used when a platform does not support native
int128_t types (e.g., riscv32).
The code here is a trimmed-down version of llvm::optional.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D150211
limits.h currently interferes with Clang's limits.h. include_next
emits a warning because it is a GNU extension. Will re add this once
we figure out a good solution.
This reverts commits 13bbca8d694b4ef2ad03ec1805f07da8640c1a31,
002cba03298a7e8f0c1cadcb7996379e9ea5feff, and
0fb3066873fdfbe28dbb6409c58a8bff7cf208c6.
This patch implements the `fopen`, `fclose`, and `fread` functions on
the GPU. These are pretty much re-implemented from what existed but
using the new interface. Having this subset allows us to test the
interface a bit more strenuously since we can write and read to a file.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D157622
This fixes the following compilation error: no known conversion from 'off_t *'
(aka 'long long *') to 'long' for 5th argument.
Since pointers are 32-bit long anyway, casting it to long shouldn't be a
problem. Tested on rv32.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D157792
The LLVM-libc build itself will override include paths and prefer it's
own limits.h over the compiler's limits.h. Because we rely on the
compiler limits.h for numerical limits in LLVM-libc it needs to be
include_next:ed if not already included. The other method to work
around this is to define all numeric macros in place.
Signed-off-by: Alfred Persson Forsberg <cat@catcream.org>
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D158040
To guarantee accuracy for all potential float values, this patch adds a
fuzzer to compare the results for float conversions from our printf
against MPFR's.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D156495
Fuzzing revealed bugs in the %e and %g conversions. Since these are very
similar, they are grouped together. Again, most of the bugs were related
to rounding. As an example, previously the code to check if the number
was truncated only worked for digits below the decimal point, due to it
being originally designed for %f. This patch adds a mechanism to check
the digits above the decimal point for both %e and %g.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D157536
Fuzzing revealed several bugs in the %f float conversion. This patch
fixes them. Most of these bugs are related to rounding, such as
1.999...999 being rounded to 2.999...999 instead of 2.000...000 due to
rounding up not properly changing the nines to zeros. Additionally, much
of the rounding infrastructure has been refactored out so it can be
shared with the other conversions.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D157535
The trailing zeroes were previously not counted when calculating the
padding, which caused a high-precision number to get too much padding.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D157534
In the same way that get_explicit_mantissa is used to get the mantissa
with all the implicit bits spelled out, get_explicit_exponent gives you
the exponent with the special cases handled. Mainly it handles the cases
where the exponent is zero, which causes the exponent to either be 1
higher than expected, or just 0.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D157156
Summary:
We implement round by implicitly converting these floating point values.
Sometimes this emits warnings that we should silence by making these
explicit casts.
The port count and index into the ports was originally written as a
64-bit number. This was with an abundance of caution, however it's
highly unlikely that any configuration will excede a 32-bit number as
most machines will require something in the low-thousands. Because GPUs
are functionally 32-bit in many of their operations this costs us some
extra time and registers to do the 64-bit operations. Doing this saves
us about four registers in most tests.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D157980
This reverts commit 7d06f59b60e6eaebd125dad351a20108f057940b.
This patch broke libc compilation with gcc as it doesn't seem to have
__is_trivially_destructible(T).
This patch moves the storage from inside the libc's optional class to
its own set of class, so we can support non-trivially destructible
objects.
These new classes check if the class is or isn't non trivially
destructible and instantiate the correct base class, i.e., we explicitly
call the destructor if an object is not trivially destructible.
The motivation is to support cpp::optional<UInt<128>> (used by
UInt<T>::div), which is used when a platform does not support native
int128_t types (e.g., riscv32).
The code here is a trimmed-down version of llvm::optional.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D150211
This header contains implementation specific constants.
The compiler already provides its own limits.h with numerical limits
conforming to freestanding ISO C. But it is missing extensions like
POSIX, and does for example not include <linux/limits.h> which is
expected on a Linux system, therefore, an LLVM libc implementation of
limits.h is needed for hosted (__STDC_HOSTED__) environments.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D156961
This code is creating a warning on Fuchsia, this patch should fix that
warning.
Reviewed By: mcgrathr
Differential Revision: https://reviews.llvm.org/D157546
Nvidia uses a 32-bit mask, but we store it in a common 64-bit integer to
provide it with a compatible ABI with the AMD implementaiton which may
use a 64-bit mask. Silence these warnings by explicitly casting to the
smaller value, we know this is always legal as the result will always
fit into the smaller value if it was generated on NVPTX.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D157548
For whatever reason, the CMake did not like having the `generic_`
version live in the same directory. This patch pushes them to a new
directory, which is probably clearer anyway.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D157544
