The GPU has much tighter requirements for handling IO functions.
Previously we attempted to define the GPU as one of the platform files.
Using a common interface allowed us to easily define these functions
without much extra work. However, it became more clear that this was a
poor fit for the GPU. The file interface uses function pointers, which
prevented inlining and caused bad perfromance and resource usage on the
GPU. Further, using an actual `FILE` type rather than referring to it as
a host stub prevented us from usin files coming from the host on the GPU
device.
After talking with @sivachandra, the approach now is to simply define
GPU specific versions of the functions we intend to support. Also, we
are ignoring `errno` for the time being as it is unlikely we will ever
care about supporting it fully.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D157427
Update documentaiton now that macros are laid out in a more structured way.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143911
This patch does the noisy work of removing the test opcodes from the
exported interface to an interface that is only visible in `libc`. The
benefit of this is that we both test the exported RPC registration more
directly, and we do not need to give this interface to users.
I have decided to export any opcode that is not a "core" libc feature as
having its MSB set in the opcode. We can think of these as non-libc
"extensions".
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D154848
These functions have definitions differing between C and C++. GNU
respects the C++ definitions while the LLVM libc does not. This causes
many bugs and the current hack creates other issues. Rather than hack
around this I'd rather temporarily disable these than regress with the
integration into other offloading languages. We lose test support for
them but we should be able to re-enable these once the `libc` headers
provide these correctly.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D154850
This patch adds the necessary support for the fopen and fclose functions
to work on the GPU via RPC. I added a new test that enables testing this
with the minimal features we have on the GPU. I will update it once we
have `fread` and `fwrite` to actually check the outputted strings. For
now I just relied on checking manually via the outpuot temp file.
Reviewed By: JonChesterfield, sivachandra
Differential Revision: https://reviews.llvm.org/D154519
Another low hanging fruit we can put on the GPU, this ports the tests
over to the hermetic framework so we can run them on the GPU.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D154540
This patch simply enables the `div`, `ldiv,` and, `lldiv` functions on
the GPU. This should be straightforward enough.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D154143
The RPC calls all have delays associated with them. Currently the `exit`
function does an async send and immediately exits the GPU. This can have
the effect that the RPC server never sees the exit call and we continue.
This patch changes that to first sync with the server before continuing
to perform its exit. There is still a hazard here, where the kernel can
complete before the RPC call reads back its response, but this is simply
multi-threaded hazards. This change ensures that the server *will*
always exit some time after the GPU exits.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D154112
This provides some basic motivation behind the GPU libc. Suggests are welcome.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D152028
These are the only variables I could find that use LIBC_INLINE. Note, these are namespace scoped constexpr so local linkage is implied. inline is useful here to silence clang's unused-const-variable variable. For Fuchsia, the distinction between LIBC_INLINE and LIBC_INLINE_VAR is helpful because we define LIBC_INLINE as `[[gnu::always_inline]] inline` when building with gcc. This isn't meaningful on variables.
Alternatively, we could make these variables simply constexpr and also add `[[maybe_unused]]`
Reviewed By: sivachandra, mcgrathr
Differential Revision: https://reviews.llvm.org/D152951
These functions were previously removed due to problems running the
tests with `errno` in them. This was resolved previously by making the
internal implementation of these functions use a global `errno` so that
tests can still use `errno` functionality as long as they are run with a
single thread. This allows us to re-enable these tests as a previous
patch has also resolved the issue where the `stdlib` tests could not be
hermetic due to the dependence on system rounding functions.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D153016
Update implementation status table for Date and Time Functions to include different targets.
Reviewed By: jeffbailey
Differential Revision: https://reviews.llvm.org/D151809
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
Now that a large amount of GPU tests can be run in parallel, we should
document spurious failures. It is a well-known issue that launching many
GPU applications in parallel can lead to various problems, the worst of
which being an indefinite hang.
Differential Revision: https://reviews.llvm.org/D149857
The previous patches added the necessary support for global constructors
used to register tests. This patch enables the AMDGPU target to build
and run the unit tests on the GPU. Currently this only tests the `ctype`
tests, but adding more should be straightforward from here on.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149517
This patch simply enables building the integer `abs` functions for the
GPU.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149317
This patch enables us to use the existing `libc` support for string
conversion functions on the GPU. This required setting the `fenv_t` and
long double configuration. As far as I am aware, long doubles are
converted to doubles on the GPU and the floating point environment is
just an `uint32_t`.
This code is still untested as we are still working out how to run the
unit tests on the GPU.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D149306
This patch updates some of the documentation for the GPU libc project.
There is a lot of work still to be done, but this sets the general
outline.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D149194
added getchar and getchar_unlocked which are just wrappers getc and getc_unlocked respectively.
Reviewed By: sivachandra, lntue, michaelrj
Differential Revision: https://reviews.llvm.org/D147919
Simplify the range reduction steps by choosing the reduction constants
carefully so that the reduced arguments v = r*m_x - 1 and v^2 are exact in double
precision, even without FMA instructions, and -2^-8 <= v < 2^-7. This allows the
polynomial evaluations to be parallelized more efficiently.
Reviewed By: zimmermann6
Differential Revision: https://reviews.llvm.org/D147676
Fixes#59277 - The main part of that bug has already been addressed. This commit
just adds documentation.
Reviewed By: jeffbailey
Differential Revision: https://reviews.llvm.org/D146115
* Add various options so that it uses the build lld and compiler-rt
* Add instructions on how to use the newly built libc
* Remove trailing comments in code-block for cut and pastability
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D145878
The entrypoint has been added to the various entrypoint lists. The libc
code style doc has been updated with information on how errno should be
set from the libc runtime code.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D145179
Add bazel targets and unit tests for single precision exponential,
logarithm, trigonometric, inverse trig, hyperbolic, and inverse hyperbolic
functions.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143275
These were using ” ("right double quotation mark") instead of
the usual ". This means CMake took the value literally and you
got:
```
CMake Error at CMakeLists.txt:139 (MESSAGE):
”libc” isn't a known project:
bolt;clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;lld;lldb;mlir;openmp;polly;pstl;flang.
Did you mean to enable it as a runtime in LLVM_ENABLE_RUNTIMES?
```
`="libc"` works fine.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D143254
