| Age | Commit message (Collapse) | Author |
|---|
|
This PR aims to add the groundwork to test the precision of libc complex
functions against MPC. I took `cargf` as a test to verify that the infra
works fine.
|
|
|
|
Summary:
The libc build has a few utilties that need to be built before we can do
everything in the full build. The one requirement currently is the
`libc-hdrgen` binary. If we are doing a full build runtimes mode we
first add `libc` to the projects list and then only use the `projects`
portion to buld the `libc` portion. We also use utilities for the GPU
build, namely the loader utilities. Previously we would build these
tools on-demand inside of the cross-build, which tool some hacky
workarounds for the dependency finding and target triple. This patch
instead just builds them similarly to libc-hdrgen and then passses them
in. We now either pass it manually it it was built, or just look it up
like we do with the other `clang` tools.
Depends on https://github.com/llvm/llvm-project/pull/84664
|
|
Summary:
This is a massive patch because it reworks the entire build and
everything that depends on it. This is not split up because various bots
would fail otherwise. I will attempt to describe the necessary changes
here.
This patch completely reworks how the GPU build is built and targeted.
Previously, we used a standard runtimes build and handled both NVPTX and
AMDGPU in a single build via multi-targeting. This added a lot of
divergence in the build system and prevented us from doing various
things like building for the CPU / GPU at the same time, or exporting
the startup libraries or running tests without a full rebuild.
The new appraoch is to handle the GPU builds as strict cross-compiling
runtimes. The first step required
https://github.com/llvm/llvm-project/pull/81557 to allow the `LIBC`
target to build for the GPU without touching the other targets. This
means that the GPU uses all the same handling as the other builds in
`libc`.
The new expected way to build the GPU libc is with
`LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`.
The second step was reworking how we generated the embedded GPU library
by moving it into the library install step. Where we previously had one
`libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This
patch includes the necessary clang / OpenMP changes to make that not
break the bots when this lands.
We unfortunately still require that the NVPTX target has an `internal`
target for tests. This is because the NVPTX target needs to do LTO for
the provided version (The offloading toolchain can handle it) but cannot
use it for the native toolchain which is used for making tests.
This approach is vastly superior in every way, allowing us to treat the
GPU as a standard cross-compiling target. We can now install the GPU
utilities to do things like use the offload tests and other fun things.
Some certain utilities need to be built with
`--target=${LLVM_HOST_TRIPLE}` as well. I think this is a fine
workaround as we
will always assume that the GPU `libc` is a cross-build with a
functioning host.
Depends on https://github.com/llvm/llvm-project/pull/81557
|
|
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D148602
|
|
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
|
