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.
Memory functions get the basic implementation. They can be tuned
as a follow up.
Reviewed By: michaelrj, lntue
Differential Revision: https://reviews.llvm.org/D145433
The test binaries are built like any other executable but with two
additional linker options -static and -nostdlib.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D145298
The entrypoint has been added to the various entrypoint lists. The libc
code style doc has been updated with information on how errno should be
set from the libc runtime code.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D145179
Lint targets for individual entrypoints have also been cleaned up. The
target "libc-lint" depends on the individual lint targets.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D144705
The target "check-libc" now runs all enabled tests which, depending on
the build mode, includes the unit tests, the integration tests and the api
test.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D144663
This patch adjusts the way dependencies are handled in the packaed
version of the GPU libc runtime. Previously the files were not getting
updated properly in the install when they changed.
Depends on D144214
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D144280
This patch unifies the handling of generating the GPU build targets
between the `add_entrypoint_library` and the `add_object_library`
functions. The `_build_gpu_objects` function will create two targets.
One contains a single object file with several GPU binaries embedded in
it, a so-called fatbinary. The other is a direct compile of the
supported target to be used internally only. This patch pulls out some
of the properties logic so that we can handle both more easily. This
patch also required adding an ovverride `NO_GPU_BUILD` for cases when
we only want to build the source file as normal.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D144214
Summary:
This hack with stub files is used to make the final object archive
have human-understandable names. We currently output these into the
current binary directory, which sometimes interferes with the actual
source file. Put these in their own directory to be certain they don't
conflict.
Before this change, the test binaries were executed only if the deps
changed. This change makes the test binaries run unconditionally. This
is more in line with the rest of LLVM. Future patches will print test
statistics etc., much like the rest of LLVM.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D143627
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.
Instead of using a custom target to copy the startup object file to a
file with the desired name, a normal object library with a special
property is used.
Follow up patches will do more cleanup wrt how the startup objects are
used in integration tests.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D143464
Currently, the plan is to support testing on a single GPU architecture.
We query the supported architectures from the user's system. However,
there are times when the user would want to override this. This patch
adds the `LIBC_GPU_TEST_ARCHITECTURE` option, which allows users to
specify which GPU architecture to build for.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D143400
instructions.
For clang-11, having -mfma without -mavx2 does not generate fma
instructions, causing a build bot to fail on log10_test.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143234
The current `libcgpu.a` is actually an archive of fatbinaries. The host
file contains nothing but a section called `LLVM_OFFLOADING` that
contains embedded device code. This used to be handled implicitly by
borrowing the OpenMP toolchain, which did this packaging internally.
Passing the OpenMP flags causes problems with trying to move to testing.
This patch pulls this logic out into the CMake and handles it manually.
This patch is a lot of noise, but it fundamentally comes down to the
following changes.
1. Build the source for every GPU architecture (GPU architectures are
generally not backwards compatible)
2. Combine all of these files into a single binary blob
3. Embed that binary blob into a host file
4. Package these host files into a `.a` archive.
5. The device code will be extracted and managed by the offloading
linker.
Another important point. Right now we are maintaining an important
distinction with the GPU build. That is, when we build the exported
library we will build for many GPU architectures. However, the internal
version will only be built for a single GPU architecture, one that was
found on the user's system. This is intended to be used for internal
testing, very similar to the current path where `libc` is compiled for a
single target triple.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143089
Recently the `nvptx-arch` tool was added to address the lack of a
similar tool for detecting locally installed NVIDIA GPUs. This patch
adds similar functionality for the already existing `amdgpu-arch` tool
in libc. These will be used to run tests on the user's system in the
future. On a system with both GPUs installed we will just go with the
first GPU detected. In the future we may want to configure the tests to
run on both of them.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D142776
This feature will primarily by used by the runtimes build. In the
runtimes build, we build libc-hdrgen once for the host and use it
to build the libc for other targets. So, the host libc-hdrgen is
like a prebuilt passed to the target builds.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D141426
Currently LIBC_TARGET_OS query from compiler triple returns `apple` for
macOS. This change will fix it back to `darwin` as before.
Differential Revision: https://reviews.llvm.org/D141282
This implements the same behavior as D141997 but makes sure that the same detection mechanism is used between CMake and source code.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D142108
This implements the same behavior as D141997 but makes sure that the same detection mechanism is used between CMake and source code.
Differential Revision: https://reviews.llvm.org/D142108
This patch reduces CMake configuration time drastically by removing a non-linear behavior.
Time to execute CMake configure step goes from 45s to 15s.
Differential Revision: https://reviews.llvm.org/D142374
This implements the same behavior as D141997 but makes sure that the same detection mechanism is used between CMake and source code.
Differential Revision: https://reviews.llvm.org/D142108
