A target for the test named ${fq_target_name} has been added. It depends
on ${fq_target_name}.__unit__ and ${fq_target_name}.__hermetic__ as
relevant.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D149730
The previous patches added the necessary support for global constructors
used to register tests. This patch enables the NVPTX 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.
This ran all the ctest unit tests when run on an sm_70.
Depends on D149517 D149527
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149532
This patch adds the necessary hacks to support global constructors and
destructors. This is an incredibly hacky process caused by the primary
fact that Nvidia does not provide any binary tools and very little
linker support. We first had to emit references to these functions and
their priority in D149451. Then we dig them out of the module once it's
loaded to manually create the list that the linker should have made for
us. This patch also contains a few Nvidia specific hacks, but it passes
the test, albeit with a stack size warning from `ptxas` for the
callback. But this should be fine given the resource usage of a common
test.
This also adds a dependency on LLVM to the NVPTX loader, which hopefully doesn't
cause problems with our CUDA buildbot.
Depends on D149451
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D149527
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
The `-v` flag means verbose and not version.
With `clang` this flag prints the version and exits successfully.
Under `GCC` this is not a valid command line so the binary exits with
an error.
We previously changed this to use `nolibc` to allow it to link in
compiler builtins for the CPU build. However, these options are unused
on the GPU and create a lot of noise. Furthermore, we want to use
`nogpulib` to prevent the linking in of the vendor libraries.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149753
We previously used a more stricter -nostdlib option which was also removing
compiler-rt/libgcc.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D149683
The `add_libc_test` option allows us to enable both kinds of tests in a
single option. However, some tests cannot be made hermetic with the
current approach. Such as tests that rely on system utilities or
libraries. This patch adds two options `UNIT_TEST_ONLY` and
`HERMETIC_TEST_ONLY` to offer more fine-grained control over which
version gets built. This makes it explicit which version a test supports
and why.
Depends on D149662
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149691
This patch addresses some of the flags and features that are currently
missing from the hermetic test support. This mostly just fixes the
`add_libc_test` option failing to find a few dependencies or missing
arguments from the previous unit test support.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D149629
The existing LibcTestMain has been renamed to LibcUnitTestMain.
Hermetic tests are linked to LibcHermeticTestMain and unit tests are
linked to LibcUnitTestMain.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D149303
We need to perform the GPU build separately. The `CXX_STANDARD` option
was not being passed properly.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149225
A convenience wrapper name `add_libc_test` is also added which adds both
a unit test and a hermetic test. The ctype tests have been switched over
to use add_libc_test.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D148756
Previously, only those unit tests which belonged to a suite were run as
part of libc-unit-tests. It meant that unit tests not part of any suite
were not being tested. This change makes all unit tests run as part of
libc-unit-tests. The convenience function to add a libc unit test suite
has been removed and add_custom_target is used in its place. One of the
bit-rotting test has along been fixed. Math exhaustive and differential
tests are skipped under full build.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D148784
Summary:
We generally need a CUDA toolchain to build the tests for the GPU `libc`
targeting NVPTX. However, clang will commonly emit warnings on versions
that are too new. We can ignore these in `libc` since we are manually
specifying the `+ptx` version to use whenever we compile. So we do not
need to worry about unexpected changes and we do not depend on any newer
features. So this should not be problematic.
Summary:
The sm_60 GPU is the oldest model that's supported for using the RPC
features of the `libc` GPU runtime. This also requires at least `+ptx63`
to enable use of the active mask. So, this patch sets that as the
minimum.
Summary:
The `+ptx` features correspond to the related CUDA version. We require a
certain set of features from the `ptxas` assembler, which is tied to the
CUDA version. Some of the ones set here were insufficient, so I am
simply setting a cutoff to the CUDA 9.0 release as the minimum. This
roughly corresponds to what should be required for sm_60 to be compiled
with the source.
After the switch to `add_custom_target` to run integration tests, most
of them were not actually being run because of the difference in the way
the COMMAND value is treated between `add_custom_target` and
`add_custom_command`. This patch gets the integration tests to run
again by passing the correct set of arguments to `add_custom_target`.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D148786
Summary:
We have a CMake condition to not include this static library on NVPTX
because their linker doesn't support it. There was a typo that made this
trigger on all builds not just the NVPTX ones.
The RPC interface can support multiple independent clients. This support
currently only supports many single-thread warps / workgroups
coordinating over a single lock. This patch uses the support added in
the previous patch to test the RPC interface with multiple blocks.
Note that this does not work with multiple threads currently because of
the effect of warps / workgroups executing in lockstep incorrectly. This
will be added later.
Depends on D148485
Reviewed By: lntue, sivachandra
Differential Revision: https://reviews.llvm.org/D148486
Summary:
This variable was not being reset, which caused the options to be
compounded when building multiple architectures. This was very
problematic as the architectures are not compatible.
The NVIDIA compilation path requires some special options. This is
mostly because compilation is dependent on having a valid CUDA
toolchain. We don't actually need the CUDA toolchain to create the
exported `libcgpu.a` library because it's pure LLVM-IR. However, for
some language features we need the PTX version to be set. This is
normally set by checking the CUDA version, but without one installed it
will fail to build. We instead choose a minimum set of features on the
desired target, inferred from
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#release-notes
and the PTX refernece for functions like `nanosleep`.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D148532
Summary:
The `nvlink` linker doesn't support static libraries, so we just pass in
the object files. The condition was erroneously doing this for every
single GPU architecture and not just NVIDIA. The AMDGPU support handles
static libraries just fine.
Summary:
When we detect the architectures via `native` we can have systems with
multiple of the same GPU. We need to remove duplicates or else we will
try to build the same target multiple times.
Let RISCV64 targets math implementations with and without FMA
automatically.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D146730
Summary:
If the target for these tools doesn't exist we should simply assume that
they will be provided externally. This allows building `libc` standalone
with an external installation of `clang`.
The packaged version of the `libc` library does not depend on the CUDA
installation because it only uses `clang` and emits LLVM-IR. However,
for testing we directly need the CUDA toolkit to emit and execute the
files. This patch explicitly passes `--cuda-path` to the relevant
compilations for NVPTX testing.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D147653
Summary:
The AMDGPU ABI isn't stable or well defined. For that reson we prefer to
rely on LTO to ensure that multiple files get linked correctly.
Currently the internal targets used for testing mix LLVM-IR and
assembly. We should be consistent here.
We already use the `amdgpu-arch` and `nvptx-arch` tools to determine the
GPU architectures the user's system supports. We can provide
`LIBC_GPU_ARCHITECTURES=native` to allow users to easily build support
for only the one found on their system. This also cleans up the code
somewhat.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D146994
Currently the GPU build requires the `LLVM_LIBC_FULL_BUILD` option to be
set. This patch changes the logic so that it is always enabled when
targeting the GPU. Also, this patch allows `LIBC_GPU_BUILD` and
`LIBC_GPU_ARCHITECTURES` to both enable a GPU build. Now, enabling the
GPU support should only require the following CMake:
```
-DLLVM_ENABLE_RUNTIMES=libc -DLIBC_GPU_ARCHITECTURES=gfx1030
```
Reviewed By: jdoerfert, sivachandra
Differential Revision: https://reviews.llvm.org/D146979
This patch adds the necessary build infrastructure to build and run the
integration tests on NVIDIA GPUs. The NVIDIA `nvlink` linker utility is
what is ultimately used to combine these files into a single executable
image. Unfortunately, their tool does not support static libraries. So
we need to link with every object directly instead. This could be solved
by impelementing a "wrapper" utility around `nvlink` like we used to use
for OpenMP. But for now this should be sufficient.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D146861
This patch enables integration tests running on the GPU. This uses the
RPC interface implemented in D145913 to compile the necessary
dependencies for the integration test object. We can then use this to
compile the objects for the GPU directly and execute them using the AMD
HSA loader combined with its RPC server. For example, the compiler is
performing the following actions to execute the integration tests.
```
$ clang++ --target=amdgcn-amd-amdhsa -mcpu=gfx1030 -nostdlib -flto -ffreestanding \
crt1.o io.o quick_exit.o test.o rpc_client.o args_test.o -o image
$ ./amdhsa_loader image 1 2 5
args_test.cpp:24: Expected 'my_streq(argv[3], "3")' to be true, but is false
```
This currently only works with a single threaded client implementation
running on AMDGPU. Further work will implement multiple clients for AMD
and the ability to run on NVPTX as well.
Depends on D145913
Reviewed By: sivachandra, JonChesterfield
Differential Revision: https://reviews.llvm.org/D146256
This generalizes handling of the integration tests. We now implicitly
depend on the `libc.startup.${LIBC_TARGET_OS}.crt1` file rather than
passing it in manually. This simplifies the interface.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D146237
All integration tests rely on the startup code to be run. Currently we
manually include a few of these dependencies that are relevant for the
Linux target. This patch changes this to make the integration test's
dependencies include all the dependencies of the startup code. This
simplifies the code and makes it easier to support different targets.
The changes here cause the integration test to be dependent on more
targets than previously necessary, but it should be fine.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D146184
The integration tests require the C memory functions as the compiler may
emit calls to them directly. The tests normally use the `__internal__`
variant that is built for testing, but these memory functions were
linked directly to preserve the entrypoint. Instead, we forward delcare
the internal versions and map the entrypoints to them manually inside
the integration test. This allows us to use the internal versions of
these files like the rest of the test objects.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D146177
Summary:
We use `-Xclang` to pass the GPU binary to be embedded. In the case of
multi-source objects this will be passed more than once, but CMake
implicitly deduplicates arguments. Use the special generator to prevent
this from happening.
Summary:
Multi-source object libraries require some additional handling, this
logic wasn't correctly settending the dependency on each filename
individually and was instead using the last one. This meant that only
the last file was built for multi-object libraries.
The GPU target requires some weird special case handling to create fat
binaries. CMake offers no way to set the name of an object library. The
only way to do this is to create a file with the desired name and use
that. Currently we name it after the source filename. However, this
breaks if there is more than a single source. This patch changes the
logic to instead look up the object target name and use that. E.g.
`src.__support.OSUtil.osutil` will be `osutil.cpp`.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D145912
Summary:
We use an internal option to create the GPU binary used for testing.
This wasn't getting the proper flags passed to it due to a missing
variable name.
