Summary:
The `nvlink-wrapper` can do LTO now, which means we can still create
some LLVM-IR without needing an architecture. In the case that we try to
invoke `nvlink` internally, that will still fail. This patch simply
defers the error until later so we can use `--lto-emit-llvm` to get the
IR without specifying an architecture.
Summary:
The GPU build provides a bitcode version of the library to mimic how
NVIDIA and AMD provide their libraries. Previously we had the fatbinary
archive that created the necessary dependency for this to actually
build. Since it was removed we no longer had anything triggering this to
build.
I have no idea if there's a better way to force a custom command to
actually be run in the same space as libraries, but the only thing I
could come up with was a dummy target.
Summary:
I forgot that the OpenMP tests still look for this, reverting for now
until I can make a fix.
This reverts commit c1c6ed83e9ac13c511961e5f5791034a63168e7e.
Summary:
Previously, the GPU built the `libc` in a fat binary version that was
used to pass this to the link job in offloading languages like CUDA or
OpenMP. This was mostly required because NVIDIA couldn't consume the
standard static library version. Recent patches have now created the
`clang-nvlink-wrapper` which lets us do that. Now, the C library is just
included implicitly by the toolchain (or passed with -Xoffload-linker
-lc).
This code can be fully removed, which will heavily simplify the build
(and removed some bugs and garbage files I've encoutnered).
Summary:
These tools need to be built before we can do the library creation
stage. If they are generated in the same build then this is not
guaranteed so we should add explicit dependencies.
Summary:
Recent patches have allowed us to treat these libraries as direct
builds. This makes it easier to simply build them to a single LLVM-IR
file. This matches the way these files are presented by the ROCm and
CUDA toolchains and makes it easier to work with.
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
printf_core.parser is not yet updated to use the printf config options. It
does not use them currently anyway and the corresponding parser_test
should be updated to respect the config options.
The internal header library target with name suffix `.__header_library`
has been removed as it serves no purpose now. It was added to make older
versions of CMake happy.
The options added via COMPILE_OPTIONS will be treated as INTERFACE
options. This will help in setting compile options based on libc config
options in future patches.
Summary:
A previous introduced a new object type for the GPU functions
implemented by an external vendor library. This was done so they we did
not attempt to run tests on functions which we did not implement,
however this accidentally stopped them from being included in the actual
output. Fix this by checking the new type as well.
The long term goal is to remove this vendor handling altogether, but is
being used as a short-term solution to provide a math library on the
GPU which currently lacks one.
We currently remap vendor implementations of math functions to provide a
temporarily functional `libm.a` for the GPU. However, we should not run
tests on any files that depend on these vendor implementations as they
are not under our control and are not always present.
The goal in the future is to remove the need for this by replacing all
the vendor functionality, but for now this is a workaround.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D158213
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
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
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
list(POP_FRONT) is only added to cmake in 3.15, while our base line
version is 3.13
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D127129
Add FLAGS option for add_header_library, add_object_library,
add_entrypoint_object, and add_libc_unittest.
In general, a flag is a string provided for supported functions under the
multi-valued option `FLAGS`. It should be one of the following forms:
FLAG_NAME
FLAG_NAME__NO
FLAG_NAME__ONLY
A target will inherit all the flags of its upstream dependency.
When we create a target `TARGET_NAME` with a flag using (add_header_library,
add_object_library, ...), its behavior will depend on the flag form as follow:
- FLAG_NAME: The following 2 targets will be generated:
`TARGET_NAME` that has `FLAG_NAME` in its `FLAGS` property.
`TARGET_NAME.__NO_FLAG_NAME` that depends on `DEP.__NO_FLAG_NAME` if
`TARGET_NAME` depends on `DEP` and `DEP` has `FLAG_NAME` in its `FLAGS`
property.
- FLAG_NAME__ONLY: Only generate 1 target `TARGET_NAME` that has `FLAG_NAME`
in its `FLAGS` property.
- FLAG_NAME__NO: Only generate 1 target `TARGET_NAME.__NO_FLAG_NAME` that
depends on `DEP.__NO_FLAG_NAME` if `DEP` is in its DEPENDS list and `DEP`
has `FLAG_NAME` in its `FLAGS` property.
To show all the targets generated, pass SHOW_INTERMEDIATE_OBJECTS=ON to cmake.
To show all the targets' dependency and flags, pass
`SHOW_INTERMEDIATE_OBJECTS=DEPS` to cmake.
To completely disable a flag FLAG_NAME expansion, set the variable
`SKIP_FLAG_EXPANSION_FLAG_NAME=TRUE`.
Reviewed By: michaelrj, sivachandra
Differential Revision: https://reviews.llvm.org/D125174
Previously, building LLVM-libc with GWP ASAN was conditioned on the flag
COMPILER_RT_BUILD_GWP_ASAN, which caused issues do to the default value
of the flag being set in the compiler-rt cmake, which is seperate. Now
GWP ASAN is included based on if it exists as a target, which is more
consistent.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D119789
malloc, calloc, realloc, and free are all functions that other libc
functions depend on, but are pulled from external sources, instead of
having an internal implementation. This patch adds a way to include
functions like that as entrypoints in the list of external entrypoints,
and includes the malloc functions using this new path.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D112104
This patch adds LLVM_LIBC_INCLUDE_SCUDO as a flag. When enabled it
should link in the standalone version of SCUDO as the allocator for LLVM
libc.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D106502
This patch provides a way to specify the default target cpu optimizations to use when compiling llvm-libc.
This ensures we don't rely on current compiler's default and allows compiling and cross compiling for a particular target.
Differential Revision: https://reviews.llvm.org/D101991
This reverts commit a8086ba4ac85152d8407630e56e9ee5c8b46a214.
Setting couple of target properties to an empty string was missed in the
previous commit.
Deps are recrusively evaluated at the place they are needed. With this
change, one does not have to list recursive deps of entrypoints when
listing test targets. One will still have to explicitly list all
entrypoint objects when setting up an "add_entrypoint_library" target.
Reviewers: abrachet
Differential Revision: https://reviews.llvm.org/D78537
Summary:
The single file was getting too long to be convenient to navigate. This
patch splits it up two into 4 files one each for header rules,
object rules, library rules, and test rules.
Reviewers: abrachet, alexshap
Subscribers: mgorny, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D78536
