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.
The config currently includes ctype, math, stdlib, inttypes and string
functions.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D140378
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
All existing loader tests are switched to an integration test added with
the new rule. Also, the getenv test is now enabled as an integration test.
All loader tests have been moved to test/integration. Also, the simple
checker library for the previous loader tests has been moved to a
separate directory of its own.
A follow up change will perform more cleanup of the loader CMake rules
to eliminate now redundent options.
Reviewed By: lntue, michaelrj
Differential Revision: https://reviews.llvm.org/D122266
The idea is to move all pieces related to the actual libc sources to the
"src" directory. This allows downstream users to ship and build just the
"src" directory.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D112653
Some ctype functions are called from other libc functions (e.g. isspace
is used in atoi). By moving ctype_utils.h to __support it becomes easier
to include just the implementations of these functions. For these
reasons the implementation for isspace was moved into
ctype_utils as well.
FPUtils was moved to simplify the build order, and to clarify which
files are a part of the actual libc.
Many files were modified to accomodate these changes, mostly changing
the #include paths.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D107600
This option will build LLVM libc as a full libc by itself. In this mode,
it is not expected that it will be mixed with other libcs. The
non-full-build mode will be the default LLVM libc build mode. In a future
where LLVM libc is complete enough, the full libc build will be made the
default mode.
This is useful when cross-compiling libc to another target in which
case we first need to compile libc-hdrgen for host. We rely on the
existing LLVM CMake infrastructure for that.
Differential Revision: https://reviews.llvm.org/D95205
This tool will be used to generate C wrappers for the C++ LLVM libc
implementations. This change does not hook this tool up to anything yet.
However, it can be useful for cases where one does not want to run the
objcopy step (to insert the C symbol in the object file) but can make use
of LTO to eliminate the cost of the additional wrapper call. This can be
relevant for certain downstream platforms. If this tool can benefit other
libc platforms in general, then it can be integrated into the build system
with options to use or not use the wrappers. An example of such a
platform is CUDA.
Reviewed By: abrachet
Differential Revision: https://reviews.llvm.org/D84848
This class is currently used by two tools: HdrGen and PrototypeTestGen.
We will be adding more tools based on this class so it is convenient to
keep it in a util library of its own.
Summary:
To get the target order correct, the benchmarks directory has been moved
one level higher. Previously, it was living in the utils directory. The
utils directory is a collection of utils which are to be used by the
tests and implementations. However, benchmarks *use* the
implementations. So, moving it out of utils helps us setup proper
target level dependencies.
Reviewers: gchatelet
Differential Revision: https://reviews.llvm.org/D81910
A new utils library named 'fputil' is added. This library is used in
math tests and the MPFR wrapper. The math implementations will be
modified to use this library in a later round.
Reviewers: phosek
Differential Revision: https://reviews.llvm.org/D79724
NFC intended in the implementaton. Only mechanical changes to fit the LLVM
libc implementation standard have been done.
Math testing infrastructure has been added. This infrastructure compares the
results produced by the libc with the high precision results from MPFR.
Tests making use of this infrastructure have been added for cosf, sinf and
sincosf.
Reviewers: abrachet, phosek
Differential Revision: https://reviews.llvm.org/D76825
Summary: This patch adds `EXPECT_EXITS` and `EXPECT_DEATH` macros for testing exit codes and deadly signals. They are less convoluted than their analogs in GTEST and don't have matchers but just take an int for either the exit code or the signal respectively. Nor do they have any regex match against the stdout/stderr of the child process.
Reviewers: sivachandra, gchatelet
Reviewed By: sivachandra
Subscribers: mgorny, MaskRay, tschuett, libc-commits
Differential Revision: https://reviews.llvm.org/D74665
Some of the existing utils in utils/UnitTest/Test.h have been moved to
this new library.
Reviewers: abrachet, gchatelet
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D73530
Summary:
This patch adds a benchmarking infrastructure for llvm-libc memory functions.
In a nutshell, the code can benchmark small and large buffers for the memcpy, memset and memcmp functions.
It also produces graphs of size vs latency by running targets of the form `render-libc-{memcpy|memset|memcmp}-benchmark-{small|big}`.
The configurations are provided as JSON files and the benchmark also produces a JSON file.
This file is then parsed and rendered as a PNG file via the `render.py` script (make sure to run `pip3 install matplotlib scipy numpy`).
The script can take several JSON files as input and will superimpose the curves if they are from the same host.
TODO:
- The code benchmarks whatever is available on the host but should be configured to benchmark the -to be added- llvm-libc memory functions.
- Add a README file with instructions and rationale.
- Produce scores to track the performance of the functions over time to allow for regression detection.
Reviewers: sivachandra, ckennelly
Subscribers: mgorny, MaskRay, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D72516
Header files included wrongly using <...> are now included using the
internal path names as the new unittest framework allows us to do so.
Reviewers: phosek, abrachet
Differential Revision: https://reviews.llvm.org/D72743
Summary:
* The Python header generator has been removed.
* Docs giving a highlevel overview of the header gen scheme have been
added.
Reviewers: phosek, abrachet
Subscribers: mgorny, MaskRay, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D70197
