Summary:
The AMDGPU hack can be removed, and we no longer need to skip 90% of the
`HandleLLVMOptions` if we work around NVPTX earlier. Simplifies the
interface by removing duplicated logic and keeps the GPU targets from
being weirdly divergent on some flags.
Summary:
People might want to modify this to run on older machines. Expose this
so it can be set with
`-DRUNTIMES_amdgcn-amd-amdhsa_LIBC_GPU_CODE_OBJECT_VERSION`.
This is required in hermetic testing downstream. It is not complete, and
will not work on hardware, however it runs on QEMU, and can report a
pass/fail on our tests.
Part of https://github.com/llvm/llvm-project/issues/145349. Required to
allow `atexit` to work. As part of `HermeticTestUtils.cpp`, there is a
reference to `atexit()`, which eventually instantiates an instance of a
Mutex.
Instead of copying the implementation from
`libc/src/__support/threads/gpu/mutex.h`, we allow platforms to select
an implementation based on configurations, allowing the GPU and
single-threaded baremetal platforms to share an implementation. This can
be configured or overridden.
Later, when the threading API is more complete, we can add an option to
support multithreading (or set it as the default), but having
single-threading (in tandem) is in line with other libraries for
embedded devices.
This PR simplifies how we enable the different fma configs for riscv:
1. Removes __LIBC_RISCV_USE_FMA define
2. Checks if __riscv_flen is defined to set LIBC_TARGET_CPU_HAS_FMA
As a bonus, we enable *FMA_OPT tests for rv32, so any rv32 hardware that
doesn't implement the f/d extensions is also covered by the tests.
For some reason cmake usually turns this path into an absolute path, but
sometimes
it doesn't do it and stays as a relative path, which means the command
will fail.
Specify it as an absolute path always so this doesn't happen any more.
Fixes [#141505](https://github.com/llvm/llvm-project/issues/141505)
The main intention behind this PR is to update the
LibCTargetArchitecture for arm64 to use the implementation of aarch64
architecture and not arm32.
This is a historical issue , and is a blocker to issue #138407.
The intended fix is to set the `LibCTargetArchitecture` to aarch64 when
it matches arm64 , this in turn would help us run darwin/aarch64
specific code on our MacOs pipeline in the git actions.
Methods used to search and find "darwin/arm" directories was
1. "find . -type d -path "*/libc/*/darwin/arm" in a linux terminal to
check for arm specifically
2. "find . -type d -path "*/libc/*/darwin/*" to ensure there are no
directories that are named "*arm*" where star is a wildcard for any
character.
It seems we were missing a dependency when adding a new test target,
e.g., test libc.test.src.math.sqrt_test.__unit__ would create a
custom target in the form of:
```
add_custom_target(
libc.test.src.__support.FPUtil.dyadic_float_test.__unit__
COMMAND ${LIBC_UNITTEST_ENV} ${CMAKE_CROSSCOMPILING_EMULATOR} libc.test.src.__support.FPUtil.dyadic_float_test.__unit__.__build__
COMMENT Running unit test libc.test.src.__support.FPUtil.dyadic_float_test.__unit__ )
```
but it wouldn't set that it depends on
libc.test.src.__support.FPUtil.dyadic_float_test.__unit__.__build__
being built.
For some reason, it would break the rv32 buildbot, as it would try to
run a test but the __build__ is nowhere to be found, since it wasn't
built in the first place.
Summary:
Previously, we removed the special handling for the code object version
global. I erroneously thought that this meant we cold get rid of this
weird `-Xclang` option. However, this also emits an LLVM IR module flag,
which will then cause linking issues.
Summary:
When we were first porting to COV5, this lead to some ABI issues due to
a change in how we looked up the work group size. Bitcode libraries
relied on the builtins to emit code, but this was changed between
versions. This prevented the bitcode libraries, like OpenMP or libc,
from being used for both COV4 and COV5. The solution was to have this
'none' functionality which effectively emitted code that branched off of
a global to resolve to either version.
This isn't a great solution because it forced every TU to have this
variable in it. The patch in
https://github.com/llvm/llvm-project/pull/131033 removed support for
COV4 from OpenMP, which was the only consumer of this functionality.
Other users like HIP and OpenCL did not use this because they linked the
ROCm Device Library directly which has its own handling (The name was
borrowed from it after all).
So, now that we don't need to worry about backward compatibility with
COV4, we can remove this special handling. Users can still emit COV4
code, this simply removes the special handling used to make the OpenMP
device runtime bitcode version agnostic.
Initial UEFI OS target support after the headers. This just defines
enough that stuff might try and compile. Test with:
```
$ cmake -S llvm -B build -G Ninja -DLLVM_RUNTIME_TARGETS=x86_64-unknown-uefi-llvm -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_ENABLE_RUNTIMES=libc -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_LIBC_FULL_BUILD=true -DCMAKE_C_COMPILER_WORKS=true -DCMAKE_CXX_COMPILER_WORKS=true -DLLVM_ENABLE_PROJECTS="clang;lld" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_LIBCXX=true -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-gnu -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-uefi-llvm -DCMAKE_INSTALL_LIBDIR=build/target/lib
$ ninja -C build
```
This reverts commit 1e6e845d49 because it
changed the 1st parameter of adjust() to be unsigned, but libc itself
calls adjust() with a negative argument in align_backward() in
op_generic.h.
DATA_FILES CMake argument never existed in the new YAML-based hdrgen
version of add_gen_header function, and thus its uses added in
b1fd6f0996 were always dead code.
Remove them to clean up the function implementation.
Co-authored-by: Alexey Samsonov <samsonov@google.com>
Summary:
Currently we conditionally enable NVPTX lowering depending on the
language (C/C++/OpenMP). Unfortunately this causes problems because this
option is only present if the backend was enabled, which causes this to
error if you try to make LLVM-IR.
This patch instead makes it the only accepted lowering. The reason we
had it as opt-in before is because it is not handled by CUDA. So, this
pach also introduces diagnostics to prevent *all* creation of
device-side global constructors and destructors. We already did this for
variables, now we do it for attributes as well.
This inverts the responsibility of blocking this from the backend to the
langauage like it should be given that support for this is language
dependent.
While GCC's -Wdeprecated is on by default and doesn't do much,
Clang's -Wdeprecated enables many more things. More apply in
C++20, so switch a test file that tickled one to using that. In
future, C++20 should probably be made the baseline for compiling
all the libc code.
This PR aims to add the groundwork to test the precision of libc complex
functions against MPC. I took `cargf` as a test to verify that the infra
works fine.
Summary:
This introduces libc cache files and adds one for building the GPU
support. The cache files will set defaults for these arguments which can
be overridden if the user needs to. They also serve as documentation for
how the builid is expected to look.
