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:
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
Summary:
Currently, doing `ninja install` will fail in fullbuild mode due to the
startup utilities not being built by default. This was hidden previously
by the fact that if tests were run, it would build the startup utilities
and thus they would be present.
This patch solves this issue by making the `libc-startup` target a
dependncy on the final library. Furthermore we simply factor out the
library install directory into the base CMake directory next to the
include directory handling. This change makes the `crt` files get
installed in `lib/x86_64-unknown-linu-gnu` instead of just `lib`.
This fixes an error I had where doing a runtimes failed to install its
libraries because the install step always errored.
Prior to this change, we wouldn't build headers that aren't referenced
by other parts of the libc which would result in a build error during
installation. To address this, we make the header target a dependency of
the libc archive. Additionally, we also redo the install targets, moving
the install targets closer to build targets and simplifying the
hierarchy and generally matching what we do for other runtimes.
We currently put everything in one single archive libc.a which breaks in
certain situations where the compiler drivers expect libm.a also. With
this change, we separate out libc.a and libm.a functions as is done
conventionally and put them in two different static archives.
One will now have to build two targets, `libc` and `libm` which produce
`libc.a` and `libm.a` respectively. Under default build, one still builds only
one target named `libc` which produces `libllvmlibc.a`.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D143005
Currently this logic causes the `libcgpu.a` to be installed to the
user's default triple. The GPU target isn't really true to this in a
cross-compiling sense so we should just default to the regular `/lib`
directory
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D142774
This reverts commit bec8a372fc0db95852748691c0f4933044026b25.
This causes many of these errors to appear when rebuilding runtimes part
of fuchsia's toolchain:
ld.lld: error:
/usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o)
is incompatible with elf64-x86-64
This can be reproduced by making a complete toolchain, saving any source
file with no changes, then rerunning ninja distribution.
This variable is derived from LLVM_DEFAULT_TARGET_TRIPLE by default,
but using a separate variable allows additional normalization to be
performed if needed.
Differential Revision: https://reviews.llvm.org/D137451
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
* In the full build mode, `ninja install-libc` will install the headers as
well the static archive named libc.a.
* In the default mode, `ninja install-llvmlibc` will only install the
static archive libllvmlibc.a.
Reviewed By: jeffbailey
Differential Revision: https://reviews.llvm.org/D132015
Using the LLVM rules for install ensures that DESTDIR and other expected
variables for an LLVM install work correctly.
Tested:
Manually with DESTDIR=/tmp/testinstall/ ninja install-llvmlibc
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D129041
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 change adds tests to make sure that SCUDO is being properly
included with llvm libc. This change also adds the toggles to properly
use SCUDO, as GWP-ASan is enabled by default and must be included for
SCUDO to function.
Reviewed By: sivachandra, hctim
Differential Revision: https://reviews.llvm.org/D106919
The previous patch included the implementations for the scudo allocator,
but not the wrappers. This change fixes that.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D106718
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 matches the decision made in D99697.
It also shouldn't reintroduce the issue fixed in D99636.
The variable was originally introduced in
b22f448c21e718a3b6219df89169f38d436189c6 but is not essential to that
change.
Once we finish adding `GnuInstallDirs` support in D100810 and D99484,
setting `CMAKE_INSTALL_LIBDIR` would also work to change the
installation directory (though for more than libc).
`GnuInstallDirs` support also brings up an issue which is avoided if
variables like `LIBC_INSTALL_PREFIX` don't exist. Because the
`GnuInstallDirs` variables can be absolute paths, it is a bit unclear
how the per-project prefixes would work: does the project-agnostic
role-specific variable (e.g. `CMAKE_INSTALL_LIBDIR`), or project-specfic
role-agnostic (e.g. `LIBC_INSTALL_PREFIX`) take priority? Each is more
specific than the other on one axis, but not the other.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D105740
Summary:
If a test depends on a skipped entrypoint, then the test is also
skipped. This setup will be useful as we gradually add support for
more operating systems and target architectures.
Reviewers: asteinhauser
Differential Revision: https://reviews.llvm.org/D81489
Summary:
This patch aims to add integration tests to check the following:
1) Header files are generated as expected.
2) Libc functions have the correct public name.
3) Libc functions have the correct return type and parameter types.
4) Symbols are exposed in the public lib.a files.
Reviewers: sivachandra, abrachet
Reviewed By: sivachandra
Subscribers: aheejin, ecnelises, dxf, mgorny, jfb, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D79192
Summary: Adds `write` for Linux and FDReader utility which should be useful for some stdio tests as well.
Reviewers: sivachandra, PaulkaToast
Reviewed By: sivachandra
Subscribers: mgorny, tschuett, libc-commits
Differential Revision: https://reviews.llvm.org/D78184
NFC intended in the implementaton. Only mechanical changes to fit the LLVM
libc implementation standard have been done.
Math testing infrastructure has been added. This infrastructure compares the
results produced by the libc with the high precision results from MPFR.
Tests making use of this infrastructure have been added for cosf, sinf and
sincosf.
Reviewers: abrachet, phosek
Differential Revision: https://reviews.llvm.org/D76825
Only targets setup by the special LLVM libc rules now have fully
qualified names. The naming style is similar to fully qualified names in
Python.
Reviewers: abrachet, PaulkaToast, phosek
Differential Revision: https://reviews.llvm.org/D77340
Summary:
This patch adds a Linux implementation for `signal`
It also fixes `ASSERT|EXPECT_THAT` macros
Reviewers: sivachandra, PaulkaToast, MaskRay
Reviewed By: sivachandra
Subscribers: mgorny, tschuett, libc-commits
Differential Revision: https://reviews.llvm.org/D76536
Summary:
The patch is not ready yet and is here to discuss a few options:
- How do we customize the implementation? (i.e. how to define `kRepMovsBSize`),
- How do we specify custom compilation flags? (We'd need `-fno-builtin-memcpy` to be passed in),
- How do we build? We may want to test in debug but build the libc with `-march=native` for instance,
- Clang has a brand new builtin `__builtin_memcpy_inline` which makes the implementation easy and efficient, but:
- If we compile with `gcc` or `msvc` we can't use it, resorting on less efficient code generation,
- With gcc we can use `__builtin_memcpy` but then we'd need a postprocess step to check that the final assembly do not contain call to `memcpy` (unlikely but allowed),
- For msvc we'd need to resort on the compiler optimization passes.
Reviewers: sivachandra, abrachet
Subscribers: mgorny, MaskRay, tschuett, libc-commits, courbet
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D74397
Summary: This patch adds a temporary `__assert_fail` and `assert` definition to make it available to internal llvm libc code. `__assert_fail` writes to fd 2 directly instead of `stderr`, using SYS_write. I have not put it in its own linux directory because this is temporary and it should be using stdio's api in the future. It does not currently print out the line number (although we could do that by stringifying `__LINE__` if reviewers wish).
Reviewers: sivachandra, gchatelet, PaulkaToast
Reviewed By: sivachandra
Subscribers: mgorny, MaskRay, tschuett, libc-commits
Differential Revision: https://reviews.llvm.org/D75420
These functions only support locking and unlocking of plain mutexes.
They will be extended in future changes to handled recursive and timed
mutexes.
Reviewers: phosek
Differential Revision: https://reviews.llvm.org/D74653
The following are the differences from the first version:
1. The kernel does not copy the stack for the new thread (it cannot).
The previous version missed this fact. In this new version, the new
thread's start args are copied on to the new stack in a known location
so that the new thread can sniff them out.
2. A start args sniffer for x86_64 has been added.
2. Default stack size has been increased to 64KB.
Reviewers: abrachet, phosek
Differential Revision: https://reviews.llvm.org/D75818
