Implement double precision log10 function correctly rounded for all
rounding modes. This implementation currently needs FMA instructions for
correctness.
Use 2 passes:
Fast pass:
- 1 step range reduction with a lookup table of `2^7 = 128` elements to reduce the ranges to `[-2^-7, 2^-7]`.
- Use a degree-7 minimax polynomial generated by Sollya, evaluated using a mixed of double-double and double precisions.
- Apply Ziv's test for accuracy.
Accurate pass:
- Apply 5 more range reduction steps to reduce the ranges further to [-2^-27, 2^-27].
- Use a degree-4 minimax polynomial generated by Sollya, evaluated using 192-bit precisions.
- By the result of Lefevre (add quote), this is more than enough for correct rounding to all rounding modes.
In progress: Adding detail documentations about the algorithm.
Depend on: https://reviews.llvm.org/D136799
Reviewed By: zimmermann6
Differential Revision: https://reviews.llvm.org/D139846
To improve code generation for C++ code that directly includes our
headers, the external function definitions will now be marked noexcept.
This may not be necessary for the internal definitions since we build
with the -fno-exceptions flag.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D141095
GCC complains about if conditions not being constant expressions.
As-is get_table_negative cannot be marked constexpr.
Differential Revision: https://reviews.llvm.org/D140967
one of the tests in StrtolTest.h is intended to detect that 32 bit longs
are handled correctly, but it wasn't using the correct value for errno
causing failures.
Differential Revision: https://reviews.llvm.org/D140577
Few uses of free have not yet been replaced by the custom operator
delete yet. They will be done in a follow up patch.
Reviewed By: lntue, michaelrj
Differential Revision: https://reviews.llvm.org/D140526
Previously the tests were copy/pasted into several files, this changes
them to be instead templated and sharing one file.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D140441
Add support for the %e/E conversion in printf, as well as unit tests. It
does not yet support long doubles.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D140042
This can be easily resurrected if required in future. It calls malloc
directly. So, instead of updating an unused piece to the newer pattern
of using the custom operator new, this patch just deletes it.
The config currently includes ctype, math, stdlib, inttypes and string
functions.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D140378
We need to know which, if any, GPUs the user has on their system if we
want to be able to test the `libc` source code for the GPU. This patch
adds a basic check using the `amdgpu-arch` utility which is provided by
`clang`.
Checking for NVIDIA GPUs will be done later as this is a little
problematic right now. CMake provides a method that we use for Clang but
it will soon be deprecated, the replacement requires a newer CMake
version that we will have in the LLVM 17 branch in the future. CUDA also
provides `__nvcc_device_query` but it's very new so I'm not sure if we
should rely on it. I may introduce a new tool to do it similar to
`amdgpu-arch`.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D140422
We do not list macro definitions in api.td files anymore. Not all macros
definitions have been moved out. This change moves the definition of the
NULL macro out.
Reviewed By: lntue, jhuber6
Differential Revision: https://reviews.llvm.org/D140376
The string to integer conversion functions are well suited to
differential fuzzing, and this patch adds a target to enable just that.
It also fixes a bug in the fuzzing comparison logic and changes atoi
slightly to match the behavior described in the C standard.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D140178
The standard describes atoi as:
"equivalent to atoi: (int)strtol(nptr, (char **)NULL, 10)"
Previously, our behavior was slightly different on numbers larger than
INT_MAX, but this patch changes it to just do the cast instead. Both of
these are valid since the standard says
"If the value of the result cannot be represented, the
behavior is undefined."
But matching existing behavior makes differential fuzzing easier.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D140350
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
One should be able to do a cross build of the libc now. For example, using
clang on a x86_64 linux host, one can build for an aarch64 linux target by
specifying -DLIBC_TARGET_TRIPLE=aarch64-linux-gnu.
Follow up changes will add a baremetal config and also appropriate
documentation about cross compiling the libc for CPU targets.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D140351
The internal uint class had a bug introduced recently when optimizing
the shift routines. When calculating the value of a block, it would
shift an adjacent block by 64 - the shift amount. If the shift amount
was 0, this would be a shift of 64, which is undefined for a 64 bit
integer. This patch fixes this by adding a conditional to catch this
case.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D140070
