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
```
Summary:
Right now a lot of the memory functions error if we don't have specific
handling for them. This is weird because we have a generic
implementation that should just be used whenever someone hasn't written
a more optimized version. This allows us to use the `libc` headers with
more architectures from the `shared/` directory without worrying about
it breaking.
The affected line of code converts a float's exponent from `int` to
`size_t`, negating it in the process. Following clang commit
773e88f9d61399c, this provokes a warning, presumably because the
conversion goes wrong if `size_t` is wider than `int` and the input
value is `INT_MIN`: negating it within the `int` type is undefined
behavior, with the likely (though not guaranteed) effect of leaving it
still at `INT_MIN` and then sign-extending that on promotion to
`size_t`.
This fix adds a cast so that the promotion to `size_t` happens _before_
the negation, so that the negative input value will _always_ be
sign-extended, and then the negation will make it positive again.
(I don't believe this case will actually come up. `DyadicFloat` is a
helper system used in processing ordinary float formats, so nothing is
expected to generate an exponent with even a 16-bit absolute value, let
alone 31. But it's as easy to fix it to be robust as it is to just
suppress the warning!)
Summary:
This patch moves the RPC server handling to be a header only utility
stored in the `shared/` directory. This is intended to be shared within
LLVM for the loaders and `offload/` handling.
Generally, this makes it easier to share code without weird
cross-project binaries being plucked out of the build system. It also
allows us to soon move the loader interface out of the `libc` project so
that we don't need to bootstrap those and can build them in LLVM.
Commit 598e882ee88a1e3 turned `Writer` into a template, and updated most
of the call sites that use it. But not all. The alternative FP printf
system in `float_dec_converter_limited.h` wasn't updated, and neither
was `baremetal/printf.cpp` or `baremetal/vprintf.cpp`.
This patch updates `float_dec_converter_limited.h` in the same way that
the previous commit updated `float_dec_converter.h`: propagate the
templatedness through everything in the header, so that anything using a
`Writer` at all has a `write_mode` template parameter to pass on to it.
`printf.cpp` and `vprintf.cpp` are updated in the same way that the
previous commit updated `printf_core/vfprintf_internal.h`: the
`WriteBuffer` has parameter `WriteMode::FLUSH_TO_STREAM`, and `Writer`
picks it up implicitly from that.
Summary:
This is done in preparation for making this header only so we can use it
without an object library. This will be a transient interface that
internal LLVM stuff with use. External people can use it too if they go
through the LLVM libc interface for shared stuff but there's no backward
compatibility guarantees.
Patch just cleans it up prior to the move.
Summary:
Currently we dispatch the writing mode off of a runtime enum passed in
by the constructor. This causes very unfortunate codegen for the GPU
targets where we get worst-case codegen because of the unused function
pointer for `sprintf`. Instead, this patch moves all of this to a
template so it can be masked out. This results in no dynamic stack and
uses 60 VGPRs instead of 117. It also compiles about 5x as fast.
* strcpy doesn't need to depend on memcpy
* qsort_test_helper has been generalized and doesn't need to depend on
qsort.
This is a small cleanup to unblock the work outlined in #130327.
The docs build action was failing with libc due to checks.rst not
existing in the expected path. This patch adjusts the path to the actual
path which seems to make everything happy. It seems like this did not
show up before as stdfix.rst was not included in a place that actually
caused it to get picked up by sphinx.
This reverts commit 1e6e845d49a336e9da7ca6c576ec45c0b419b5f6 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.
Followup to #127523
There were some test failures on arm32 after enabling Wconversion. There
were some tests that were failing due to missing casts. Also I changed
BigInt's `safe_get_at` back to being signed since it needed the ability
to be negative.
This involved a little bit of yak shaving because one of the new tests
depends on MPC, and we didn't have targets for it yet, so I ended up
needing to add a similar setup to what we have for MPFR.
`cpp::is_complex_type_same<T1, T2>` is a function, so we need
parentheses in order to call it. Otherwise the expression is treated
like a function pointer which is always true in this boolean context.
Originated from #120687
This PR simply adds the necessary headers for UEFI which defines all the
necessary types. This PR unlocks the ability to work on other PR's for
UEFI support.
Move the hdrgen code under a subdirectory to treat it as a Python
module.
This mimics the structure used by llvm/utils/lit and
llvm/utils/mlgo-utils and simplifies integration of hdrgen to the build
system which rely on Python modules. In addition to that, it clarifies
which imports are coming from the hdrgen-specific helpers (e.g. "from
type import ..." becomes "from hdrgen.type import ...".
Leave the entrypoints (top-level main.py and yaml_to_classes.py) as-is:
they can keep being referred by the CMake build system w/o any changes.
Both fileno and fdopen require interfacing with the opaque FILE struct,
so they shouldn't be enabled in overlay mode. This patch moves both into
fullbuild only on all platforms.
Fixes#128643
DATA_FILES CMake argument never existed in the new YAML-based hdrgen
version of add_gen_header function, and thus its uses added in
b1fd6f0996a9d6e6ebfa0cc3df0fe499c5ccdf65 were always dead code.
Remove them to clean up the function implementation.
Co-authored-by: Alexey Samsonov <samsonov@google.com>
Summary:
Currently we default to non-fullbuild for all targets, but realistically
we should do this depending on the target OS. Some OS's like the GPU or
upcoming UEFI have no existing hosted system, so they cannot be built
with an overlay build. These are already errors so there's no reason to
complicate things and require passing it in through the runtimes build.
