summaryrefslogtreecommitdiff
path: root/libc/cmake
Commit message (Collapse)AuthorAgeFilesLines
* [libc] Add a convenience CMake function `add_unittest_framework_library`.Siva Chandra Reddy2023-05-171-5/+22
| | | | | | | | | | 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
* [libc] Remove *TestMain libraries and combine them with the main test libraries.Siva Chandra Reddy2023-05-161-2/+2
| | | | | | | | | | | 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
* [libc] Allows cross compilation of membenchmarksGuillaume Chatelet2023-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | 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.html https://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
* Revert "[libc] Improve the add_libc_test rule."Siva Chandra Reddy2023-05-041-8/+0
| | | | | This reverts commit fb6faf4798b1cb327e719898e2ea6eff7f597c49 as the aarch64 builders are failing.
* [libc] Improve the add_libc_test rule.Siva Chandra Reddy2023-05-041-0/+8
| | | | | | | | | | 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
* [libc] Enable running libc unit tests on NVPTXJoseph Huber2023-05-041-1/+2
| | | | | | | | | | | | | | | 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
* [libc] Support global constructors and destructors on NVPTXJoseph Huber2023-05-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | 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
* [libc] Enable running libc unit tests on AMDGPUJoseph Huber2023-05-041-4/+4
| | | | | | | | | | | 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
* [libc] Use proper flags for compiler version detectionGuillaume Chatelet2023-05-041-1/+1
| | | | | | | 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.
* [libc] Don't use '-nolibc' on the GPU buildJoseph Huber2023-05-031-1/+5
| | | | | | | | | | | 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
* [libc] Use -nolibc -nostdlib++ -nostartfiles for hermetic test link.Siva Chandra Reddy2023-05-031-1/+1
| | | | | | | | | 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
* [libc] Add 'UNIT_TEST_ONLY' and 'HERMETIC_TEST_ONLY' to 'add_libc_test'Joseph Huber2023-05-021-4/+11
| | | | | | | | | | | | | | | | 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
* [libc] Fix some missing features from the hermetic test supportJoseph Huber2023-05-021-6/+9
| | | | | | | | | | | 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
* [libc] Add a new target named LibcHermeticTestMain.Siva Chandra Reddy2023-04-261-2/+2
| | | | | | | | | | 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
* [libc] Correctly pass 'CXX_STANDARD' to the packaged GPU buildJoseph Huber2023-04-261-0/+10
| | | | | | | | | 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
* [libc] Add rule named `add_libc_hermetic_test` which adds a hermetic test.Siva Chandra Reddy2023-04-241-6/+159
| | | | | | | | | | 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
* [libc] Run all unit tests, irrespective of whether they belong to a test suite.Siva Chandra Reddy2023-04-241-5/+1
| | | | | | | | | | | | | | 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
* [libc] Suppress error message from the arch tools if they failJoseph Huber2023-04-241-1/+1
| | | | | | Summary: These tools are used to query amdgpu-arch and nvptx-arch. We shouldn't print their errors to the console if they do fail.
* [libc] Ignore unknown CUDA versions for `libc` targeting NVPTXJoseph Huber2023-04-211-0/+1
| | | | | | | | | | 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.
* [libc] Bump up sm_60's CUDA feature to +ptx63Joseph Huber2023-04-211-4/+4
| | | | | | | | 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.
* [libc] Set minimum CUDA PTX feature to +ptx60Joseph Huber2023-04-201-9/+10
| | | | | | | | | | 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.
* [libc] Actually run integration tests.Siva Chandra Reddy2023-04-201-4/+13
| | | | | | | | | | | | 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
* [libc] Fix not using the static library on amdgpuJoseph Huber2023-04-191-1/+1
| | | | | | | 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.
* [libc] Test the RPC interface with multiple blocksJoseph Huber2023-04-191-1/+2
| | | | | | | | | | | | | | | | | 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
* [libc] Fix `nvptx_options` variable not being reset in CMakeJoseph Huber2023-04-191-3/+4
| | | | | | | 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.
* [libc][NFC] Move RoundingModeUtils to LibcFPTestHelpers.Siva Chandra Reddy2023-04-181-3/+3
| | | | | | Reviewed By: lntue Differential Revision: https://reviews.llvm.org/D148602
* [libc] Add AVX detectionwqGuillaume Chatelet2023-04-182-1/+6
|
* [libc] Add special handling for CUDA PTX featuresJoseph Huber2023-04-172-6/+50
| | | | | | | | | | | | | | | | | 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
* [libc][fix] Only use the object files when targeting NVPTXJoseph Huber2023-04-171-1/+1
| | | | | | | | 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.
* [libc] Add dependency on the loader for GPU testsJoseph Huber2023-04-171-0/+1
| | | | | | Summary: We need a dependency here so the loader is up-to-date whenever we run the tests again.
* [libc] Remove duplicate architecture from the detected listJoseph Huber2023-04-141-0/+1
| | | | | | | 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.
* [libc][RISCV] Let RISCV64 targets test implementations with and without FMA.Tue Ly2023-04-062-4/+10
| | | | | | | | | Let RISCV64 targets math implementations with and without FMA automatically. Reviewed By: michaelrj Differential Revision: https://reviews.llvm.org/D146730
* [libc] Only add extra runtime dependencies if the target existsJoseph Huber2023-04-051-1/+0
| | | | | | | 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`.
* [libc] Search for the CUDA patch explicitly when testingJoseph Huber2023-04-053-1/+12
| | | | | | | | | | | | 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
* [libc][NFC] Adjust some CMake messages for the GPU buildJoseph Huber2023-03-311-1/+1
| | | | | | Summary: This disables the MPFR warning on the GPU since we can't support it anyway. Also fixes a misspelled message.
* [libc] Use LTO for AMDGPU compilation and linkingJoseph Huber2023-03-292-2/+2
| | | | | | | | 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.
* [libc] Support setting 'native' GPU architecture for libcJoseph Huber2023-03-281-69/+58
| | | | | | | | | | | | 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
* [libc] Simplify enabling the GPU build for libcJoseph Huber2023-03-272-3/+4
| | | | | | | | | | | | | | | | 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
* [libc] Enable integration tests targeting NVIDIA GPUsJoseph Huber2023-03-271-3/+8
| | | | | | | | | | | | | | 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
* [libc][NFC] Fix misspelled variable name in cmake messageJoseph Huber2023-03-231-1/+1
|
* [libc] Enable integration tests targeting the GPUJoseph Huber2023-03-171-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [libc] Remove unused startup source fileJoseph Huber2023-03-161-2/+1
| | | | | Summary: This was not removed from the previous patch. Fix that.
* [libc] Remove startup option from integration testsJoseph Huber2023-03-161-8/+7
| | | | | | | | | | 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
* [libc] Inherit integration test dependencies from the startup targetJoseph Huber2023-03-161-9/+3
| | | | | | | | | | | | | | 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
* [libc] Do not attempt to determine CPU features in GPU modeJoseph Huber2023-03-151-0/+4
| | | | | | Summary: We don't use these features in the GPU build, trying to determine them can cause errors. We should just return early if this is the case.
* [libc] Add aliases to C memory functions for integration testsJoseph Huber2023-03-151-12/+2
| | | | | | | | | | | | | | 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
* [libc] Remove leftover debug printsJoseph Huber2023-03-141-2/+0
|
* [libc] Fix CMake deduplication `-Xclang` argumentsJoseph Huber2023-03-141-1/+3
| | | | | | | | 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.
* [libc] Fix GPU fatbinary dependencies for multi-source object librariesJoseph Huber2023-03-141-2/+3
| | | | | | | | 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.
* [libc] Set the stub filename to the target name instead of the sourceJoseph Huber2023-03-141-55/+66
| | | | | | | | | | | | | | 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
View Lorry Controller Status