This library is linked into libc-hdrgen, which is compiled with
DISABLE_LLVM_LINK_LLVM_DYLIB. This option avoids linking with
libLLVM.so when LLVM_LINK_LLVM_DYLIB is specified. Unfortunately,
this can cause wierd linkage errors where symbols are defined
multiple times, with one definition coming from static linkage
and another definition coming from libLLVM.so. This is usually
apparent as a link error with options defined multiple times.
This patch adds DISABLE_LLVM_LINK_LLVM_DYLIB to this library, to
get consistent linkage of libc-hdrgen.
Differential Revision: https://reviews.llvm.org/D145839
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
This is the first attempt to get some testing support for GPUs in LLVM's
libc. We want to be able to compile for and call generic code while on
the device. This is difficult as most GPU applications also require the
support of large runtimes that may contain their own bugs (e.g. CUDA /
HIP / OpenMP / OpenCL / SYCL). The proposed solution is to provide a
"loader" utility that allows us to execute a "main" function on the GPU.
This patch implements a simple loader utility targeting the AMDHSA
runtime called `amdhsa_loader` that takes a GPU program as its first
argument. It will then attempt to load a predetermined `_start` kernel
inside that image and launch execution. The `_start` symbol is provided
by a `start` utility function that will be linked alongside the
application. Thus, this should allow us to run arbitrary code on the
user's GPU with the following steps for testing.
```
clang++ Start.cpp --target=amdgcn-amd-amdhsa -mcpu=<arch> -ffreestanding -nogpulib -nostdinc -nostdlib -c
clang++ Main.cpp --target=amdgcn-amd-amdhsa -mcpu=<arch> -nogpulib -nostdinc -nostdlib -c
clang++ Start.o Main.o --target=amdgcn-amd-amdhsa -o image
amdhsa_loader image <args, ...>
```
We determine the `-mcpu` value using the `amdgpu-arch` utility provided
either by `clang` or `rocm`. If `amdgpu-arch` isn't found or returns an
error we shouldn't run the tests as the machine does not have a valid
HSA compatible GPU. Alternatively we could make this utility in-source
to avoid the external dependency.
This patch provides a single test for this untility that simply checks
to see if we can compile an application containing a simple `main`
function and execute it.
The proposed solution in the future is to create an alternate
implementation of the LibcTest.cpp source that can be compiled and
launched using this utility. This approach should allow us to use the
same test sources as the other applications.
This is primarily a prototype, suggestions for how to better integrate
this with the existing LibC infastructure would be greatly appreciated.
The loader code should also be cleaned up somewhat. An implementation
for NVPTX will need to be written as well.
Reviewed By: sivachandra, JonChesterfield
Differential Revision: https://reviews.llvm.org/D139839
This part of the effort to make all test related pieces into the `test`
directory. This helps is excluding test related pieces in a straight
forward manner if LLVM_INCLUDE_TESTS is OFF. Future patches will also move
the MPFR wrapper and testutils into the 'test' directory.
WIFEXITED and friends expect an `int *` but these methods
were marked `const` so they instead got a `const int *`.
This macros aren't actually modifying their argument, but
we were never using these functions on an immutable
`ProcessStatus` type anyway.
To improve code generation for C++ code that directly includes our
headers, the external function definitions will now be marked noexcept.
This may not be necessary for the internal definitions since we build
with the -fno-exceptions flag.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D141095
The config currently includes ctype, math, stdlib, inttypes and string
functions.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D140378
Implement a high-precision floating point class using UInt<> as its
mantissa. This will be used in accurate pass for double precision math
functions.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D136799
Implement full multiplication `UInt<A> * UInt<B> -> UInt<A + B>` and
`quick_mul_hi` that returns the higher half of the product `UInt<A> * UInt<A>`.
These 2 functions will be used for dyadic floating point class.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D138541
This patch contains the initial support for building LLVM's libc as a
target for the GPU. Currently this only supports a handful of very basic
functions that can be implemented without an operating system. The GPU
code is build using the existing OpenMP toolchain. This allows us to
minimally change the existing codebase and get a functioning static
library. This patch allows users to create a static library called
`libcgpu.a` that contains fat binaries containing device IR.
Current limitations are the lack of test support and the fact that only
one target OS can be built at a time. That is, the user cannot get a
`libc` for Linux and one for the GPU simultaneously.
This introduces two new CMake variables to control the behavior
`LLVM_LIBC_TARET_OS` is exported so the user can now specify it to equal
`"gpu"`. `LLVM_LIBC_GPU_ARCHITECTURES` is also used to configure how
many targets to build for at once.
Depends on D138607
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D138608
When using `LLVM_ENABLE_RUNTIMES=libc` we need to perform a few extra
steps to include LLVM utilities similar to if we were performing a
standalone build. Libc depends on the tablegen utilities and the LLVM
libraries when performing a full build. When using an
`LLVM_ENABLE_PROJECTS=libc` build these are included as a part of the
greater LLVM build, but here we need to perform it maunally. This patch
should allow using `LLVM_LIBC_FULL_BUILD=ON` when building with
runtimes.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D138040
This is the first piece of scanf. It's very similar in design to printf,
and so much of the code is copied from that. There were potential issues
with conflicting macros so I've also renamed the "ASSERT_FORMAT_EQ"
macro for printf to "ASSERT_PFORMAT_EQ".
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D136288
Adding `EXPECT_MPFR_MATCH_ROUNDING_SILENTLY` macro that does not call
`explainError` when the tests fail. This is useful to check the passing or
failing rates, such as hitting percentages of fast passes in math
implementations.
Reviewed By: michaelrj, sivachandra
Differential Revision: https://reviews.llvm.org/D136731
The implementation currently ignores all spawn attributes. Support for
them will be added in future changes.
A simple allocator for integration tests has been added so that the
integration test for posix_spawn can use the
posix_spawn_file_actions_add* functions.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D135752
Implement exp10f function correctly rounded to all rounding modes.
Algorithm: perform range reduction to reduce
```
10^x = 2^(hi + mid) * 10^lo
```
where:
```
hi is an integer,
0 <= mid * 2^5 < 2^5
-log10(2) / 2^6 <= lo <= log10(2) / 2^6
```
Then `2^mid` is stored in a table of 32 entries and the product `2^hi * 2^mid` is
performed by adding `hi` into the exponent field of `2^mid`.
`10^lo` is then approximated by a degree-5 minimax polynomials generated by Sollya with:
```
> P = fpminimax((10^x - 1)/x, 4, [|D...|], [-log10(2)/64. log10(2)/64]);
```
Performance benchmark using perf tool from the CORE-MATH project on Ryzen 1700:
```
$ CORE_MATH_PERF_MODE="rdtsc" ./perf.sh exp10f
GNU libc version: 2.35
GNU libc release: stable
CORE-MATH reciprocal throughput : 10.215
System LIBC reciprocal throughput : 7.944
LIBC reciprocal throughput : 38.538
LIBC reciprocal throughput : 12.175 (with `-msse4.2` flag)
LIBC reciprocal throughput : 9.862 (with `-mfma` flag)
$ CORE_MATH_PERF_MODE="rdtsc" ./perf.sh exp10f --latency
GNU libc version: 2.35
GNU libc release: stable
CORE-MATH latency : 40.744
System LIBC latency : 37.546
BEFORE
LIBC latency : 48.989
LIBC latency : 44.486 (with `-msse4.2` flag)
LIBC latency : 40.221 (with `-mfma` flag)
```
This patch relies on https://reviews.llvm.org/D134002
Reviewed By: orex, zimmermann6
Differential Revision: https://reviews.llvm.org/D134104
Implement acosf function correctly rounded for all rounding modes.
We perform range reduction as follows:
- When `|x| < 2^(-10)`, we use cubic Taylor polynomial:
```
acos(x) = pi/2 - asin(x) ~ pi/2 - x - x^3 / 6.
```
- When `2^(-10) <= |x| <= 0.5`, we use the same approximation that is used for `asinf(x)` when `|x| <= 0.5`:
```
acos(x) = pi/2 - asin(x) ~ pi/2 - x - x^3 * P(x^2).
```
- When `0.5 < x <= 1`, we use the double angle formula: `cos(2y) = 1 - 2 * sin^2 (y)` to reduce to:
```
acos(x) = 2 * asin( sqrt( (1 - x)/2 ) )
```
- When `-1 <= x < -0.5`, we reduce to the positive case above using the formula:
```
acos(x) = pi - acos(-x)
```
Performance benchmark using perf tool from the CORE-MATH project on Ryzen 1700:
```
$ CORE_MATH_PERF_MODE="rdtsc" ./perf.sh acosf
GNU libc version: 2.35
GNU libc release: stable
CORE-MATH reciprocal throughput : 28.613
System LIBC reciprocal throughput : 29.204
LIBC reciprocal throughput : 24.271
$ CORE_MATH_PERF_MODE="rdtsc" ./perf.sh asinf --latency
GNU libc version: 2.35
GNU libc release: stable
CORE-MATH latency : 55.554
System LIBC latency : 76.879
LIBC latency : 62.118
```
Reviewed By: orex, zimmermann6
Differential Revision: https://reviews.llvm.org/D133550
The libc.src.__support.FPUtil.fputil target encompassed many unrelated
files, and provided a lot of hidden dependencies. This patch splits out
all of these files into component parts and cleans up the cmake files
that used them. It does not touch any source files for simplicity, but
there may be changes made to them in future patches.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D132980
Performance by core-math (core-math/glibc 2.31/current llvm-14):
10.845/43.174/13.467
The review is done on top of D132809.
Differential Revision: https://reviews.llvm.org/D132811
The FormatSection and the writer functions both previously took a char*
and a length to represent a string. Now they use the StringView class to
represent that more succinctly. This change also required fixing
everywhere these were used, so it touches a lot of files.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D131994
To use the FILE data structure, LLVM-libc must be in fullbuild mode
since it expects its own implementation. This means that (f)printf can't
be used without fullbuild, but s(n)printf only uses strings. This patch
adjusts the CMake to allow for this.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D131913
Previously, the integer_to_string tests used EXPECT_TRUE(.equals)
which doesn't have useful error messages. Now they properly check
equality with the EXPECT_EQ macro, which allows for comparing the
strings more naturally.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D131300
