CUDA requires a PTX feature to be compiled generally, because the
`libcgpu.a` archive contains LLVM-IR we need to have one present to
compile it. Currently, the wrapper fatbinary format we use to
incorporate these into single-source offloading languages has a special
option to provide this. Since this was not present in the builds, if the
user did not specify it via `-foffload-lto` it would not compile from
CUDA or OpenMP due to the missing PTX features. Fix this by passing it
to the packager invocation.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D154864
D152592 introduced LIBC_INCLUDE_DIR for the location of the include
directory, use it in relevant CMake rules.
Differential Revision: https://reviews.llvm.org/D154278
This is an alternate approach to the patches proposed in D153897 and
D153794. Rather than exporting a single header that can be included on
the GPU in all circumstances, this patch chooses to instead generate a
separate set of headers that only provides the declarations. This can
then be used by external tooling to set up what's on the GPU. This
leaves room for header hacks for offloading languages without needing to
worry about the `libc` implementation.
Currently this generates a set of headers that only contain the
declarations. These will then be installed to a new clang resource
directory called `llvm_libc_wrappers/` which will house the shim code.
We can then automaticlaly include this from `clang` when offloading to
wrap around the headers while specifying what's on the GPU.
Reviewed By: jdoerfert, JonChesterfield
Differential Revision: https://reviews.llvm.org/D154036
D152592 introduced LIBC_INCLUDE_DIR for the location of the include
directory, use it in relevant CMake rules.
Differential Revision: https://reviews.llvm.org/D154278
This reverts commit a4a26374aa.
This was causing some problems with the CPU build and CUDA buildbot.
Revert until I can figure out what those issues are and fix them. I
believe it is just some CMake.
This is an alternate approach to the patches proposed in D153897 and
D153794. Rather than exporting a single header that can be included on
the GPU in all circumstances, this patch chooses to instead generate a
separate set of headers that only provides the declarations. This can
then be used by external tooling to set up what's on the GPU. This
leaves room for header hacks for offloading languages without needing to
worry about the `libc` implementation.
Currently this generates a set of headers that only contain the
declarations. These will then be installed to a new clang resource
directory called `llvm_libc_wrappers/` which will house the shim code.
We can then automaticlaly include this from `clang` when offloading to
wrap around the headers while specifying what's on the GPU.
Reviewed By: jdoerfert, JonChesterfield
Differential Revision: https://reviews.llvm.org/D154036
D152592 introduced LIBC_INCLUDE_DIR for the location of the include
directory, use it in relevant CMake rules.
Differential Revision: https://reviews.llvm.org/D154278
When crt1 isn't available, which is typical on baremetal, hermetic tests
aren't created and the hermetic test target won't be available.
Differential Revision: https://reviews.llvm.org/D154279
When LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled, place headers
in `include/<target>` directory, otherwise use `include/`.
Differential Revision: https://reviews.llvm.org/D152592
Currently the GPU has restrictions on how many tests can be run in
parallel due to resource constraints. However, building these tests can
take a long time so we want to be able to build them in parallel. This
patch introduces the option `LIBC_GPU_TEST_JOBS` which is set to the
number of threads to run in parallel.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D153157
This patch moves the location of libllvmlibc.a within the build tree to
within ./lib/<target triple>. This more closely matches the behavior of
other runtime builds and allows for clang in the same build tree to
automatically be able to link against llvmlibc since this path is by
default included by the driver.
Also removes the LIBC_BINARY_DIR CMake flag since it isn't used anywhere
in the tree (based on a quick grep).
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D151624
Along the way, couple of additional things have been done:
1. Move `ErrnoSetterMatcher.h` to `test/UnitTest` as all other matchers live
there now.
2. `ErrnoSetterMatcher` ignores matching `errno` on GPUs.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D151129
We want to do this so that build system like ninja don't end up running
the hermetic and unit tests in parallel. Running in parallel can cause
problems for tests which read/write disk files as the hermetic and unit
tests can end up stepping on each other.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D151291
Also adjust pthread_create_test to accomodate large page sizes. Both
these changes should now fix the full build builders.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D151158
The previous string to float tests didn't check correctness, but due to
the atof differential test proving unreliable the strtofloat fuzz test
has been changed to use MPFR for correctness checking. Some minor bugs
have been found and fixed as well.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D150905
This function is used to add unit test and hermetic test framework libraries.
It avoids the duplicated code to add compile options to each every test
framework libraries.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D150727
There are not tests currently which use the main test framework but not
the `main` function from LibcTestMain.cpp. So, this change essentially
simplifies by merging the *TestMain libraries with the main test
libraries.
Reviewed By: michaelrj, jhuber6
Differential Revision: https://reviews.llvm.org/D150698
This patch makes sure:
- we pass the correct compiler options when building Google benchmarks,
- we only import the C++ version of the memory functions.
The change in libc/cmake/modules/LLVMLibCTestRules.cmake is here to make sure CMake can generate the right command line in the presence of the CMAKE_CROSSCOMPILING_EMULATOR option.
Relevant documentation:
https://cmake.org/cmake/help/latest/variable/CMAKE_CROSSCOMPILING_EMULATOR.htmlhttps://cmake.org/cmake/help/latest/command/add_custom_command.html#command:add_custom_command
"
If COMMAND specifies an executable target name (created by the `add_executable()` command), it will automatically be replaced by the location of the executable created at build time if either of the following is true:
- The target is not being cross-compiled (i.e. the CMAKE_CROSSCOMPILING variable is not set to true).
- New in version 3.6: The target is being cross-compiled and an emulator is provided (i.e. its CROSSCOMPILING_EMULATOR target property is set). In this case, the contents of CROSSCOMPILING_EMULATOR will be prepended to the command before the location of the target executable.
"
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D150200
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
