users can now input a new function in the CLI: the yaml, and .h will
be updated instantly
tested on different cases and does not change the yaml format in anyway
except decreasing extra spaces if present
Summary:
The `errno` variable is expected to be `thread_local` by the standard.
However, the GPU targets do not support `thread_local` and implementing
that would be a large endeavor. Because of that, we previously didn't
provide the `errno` symbol at all. However, to build some programs we at
least need to be able to link against `errno`. Many things that would
normally set `errno` completely ignore it currently (i.e. stdio) but
some programs still need to be able to link against correct C programs.
For this purpose this patch exports the `errno` symbol as a simple
global. Internally, this will be updated atomically so it's at least not
racy. Externally, this will be on the user. I've updated the
documentation to state as such. This is required to get `libc++` to
build.
Summary:
Straightforward RPC implementation of the `remove` function for the GPU.
Copies over the string and calls `remove` on it, passing the result
back. This is required for building some `libc++` functionality.
Added yaml files containing functions from only one standard.
Also added one combined standard yaml file (errno.yaml).
assert.yaml is still work in progress.
The headers installation previously missed platform-specific number
macros, and this fixes that. From discussion on LLVM discord with
`michaelrj` – ccing @michaelrj-google who hopefully is the same person 😅
N.B. I have tested this manually in my Linux Dockerfile and it appears
to do the right thing; I haven't done much more than that.
Previously headergen had a mechanism to copy the contents of one file
inot another. This wasn't ever used properly, and isn't supported by the
new headergen design. We will investigate better ways to support
different syscall definitions in future.
These are the yaml files that have combined functions from different
libraries
Rose will be adding the rest of the yaml in the next pr
Missing assert.yaml -- work in progress
python script uses yaml and classes to generate c headers
header.py is only the main class file, the rest will be in another pr
more files to be added in multiple prs
Summary:
These warnings mean that it will lower to a libcall. Previously we just
disabled it locally, which didn't work with GCC. This patch does it
globally in the compiler options if the compiler is clang.
PR for adding microbenchmarking infrastructure for NVPTX. `nvlink`
cannot perform LTO, so we cannot inline `libc` functions and this
function call overhead is not adjusted for during microbenchmarking.
Added a class representation of a libc header file, allowing for easier
conversion from YAML to .h file output.
Classes include:
- Function (representing function headers)
- Include (representing various include statements found on a header
file)
- Macro (representing macro definitions)
- Enumeration (representing enum definitions)
- Type (representing include statements for NamedTypes)
- Object (representing ObjectSpec defintitions)
Summary:
I initially didn't report these as supported because they didn't provide
expected behavior and were very wasteful. The recent patch moved them to
a lock-free atomic implementation so they can now actually be used.
Summary:
This function uses atomics now, which emit warnings on some platforms
that don't support full lock-free atomics. These aren't specifically
wrong, and in the future we could investigate a libc configuration
specialized for single-threaded microprocessors, but for now we should
get the bot running again.
Summary:
Currently, we implement the `rand` function using thread-local storage.
This is somewhat problematic because not every target supports TLS, and
even more do not support non-zero initializers on TLS.
The C standard states that the `rand()` function need not be thread,
safe. However, many implementations provide thread-safety anyway.
There's some confusing language in the 'rationale' section of
https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html,
but given that `glibc` uses a lock, I think we should make this thread
safe as well. it mentions that threaded behavior is desirable and can be
done in the two ways:
1. A single per-process sequence of pseudo-random numbers that is shared
by all threads that call rand()
2. A different sequence of pseudo-random numbers for each thread that
calls rand()
The current implementation is (2.) and this patch moves it to (1.). This
is beneficial for the GPU case and more generic support. The downside is
that it's slightly slower to do these atomic operations, the fast path
will be two atomic reads and an atomic write.
r7 is reserved in thumb2 (typically for the frame pointer, as opposed to r11 in
ARM mode), so assigning to a variable with explicit register storage in r7 will
produce an error.
But r7 is where the Linux kernel expects the syscall number to be placed. We
can use a temporary to get the register allocator to pick a temporary, which we
save+restore the previous value of r7 in.
Fixes: #93738
Summary:
This patch adds `CMAKE_REQUIRED_FLAGS` for the GPU build so checks like
`check_cxx_compiler_flags` work as expected. This is required because we
need to hack around the potential lack of `nvlink` and `ptxas` for NVPTX
targets and the fact that the AMDGPU target needs `-nogpulib` to avoid
errors on lack of ROCm. This makes a few of the checks pass and also
allows us to just check `-mcpu=native` for architecture detection
instead of finding the tools manually.
Summary:
This test fails due to alignment issues, it's likely that it's
misaligned on other targets too and they just don't crash on it.
@PiJoules maybe we should run this with ubsan?
- Algorithm:
- Step 1 - Range reduction: for a double precision input `x`, return `k`
and `u` such that
- k is an integer
- u = x - k * pi / 128, and |u| < pi/256
- Step 2 - Calculate `sin(u)` and `cos(u)` in double-double using Taylor
polynomials with errors < 2^-70 with FMA or < 2^-66 w/o FMA.
- Step 3 - Calculate `sin(x) = sin(k*pi/128) * cos(u) + cos(k*pi/128) *
sin(u)` using look-up table for `sin(k*pi/128)` and `cos(k*pi/128)`.
- Step 4 - Use Ziv's rounding test to decide if the result is correctly
rounded.
- Step 4' - If the Ziv's rounding test failed, redo step 1-3 using
128-bit precision.
- Currently, without FMA instructions, the large range reduction only
works correctly for the default rounding mode (FE_TONEAREST).
- Provide `LIBC_MATH` flag so that users can set `LIBC_MATH =
LIBC_MATH_SKIP_ACCURATE_PASS` to build the `sin` function without step 4
and 4'.
