Summary:
The RPC interface is useful for forwarding functions. This PR adds
helper functions for doing a completely bare forwarding of a function
from the client to the server. This is intended to facilitate
heterogenous libraries that implement host functions on the GPU (like
MPI or Fortran).
- Fix printf_behavior to describe NULL %s as printing "(null)" when
nullptr checks are enabled
- Point undefined_behavior NULL %s/%n entry at
LIBC_COPT_PRINTF_NO_NULLPTR_CHECKS
- Add Sphinx labels to link directly to the flag and Conversion sections
Summary:
We should likely use `-DLLVM_DEFAULT_TARGET_TRIPLE` as the general
source of truth, make the handling work with that since we use it for
the output directories. Fix the creation of startup files in this mode
and make sure it can detect the GPU properly.
Fixes: https://github.com/llvm/llvm-project/issues/179375
The str to float code path offers options which can reduce code bloat.
Expose them as build config options. Disable Eisel Lemire for avoiding
code bloat caused by DETAILED_POWERS_OF_TEN look up table.
Add support for %lc in printf by calling internal wcrtomb function and
relevant end-to-end sprintf test.
Additionally, made the following changes:
- Modified printf parser for recognizing length modifier
- Added two internal error codes.
- Added a flag to disable wchar support on windows platform.
- To keep printf interface header only, converted wcrtomb and
CharacterConverter to header only implementation and removed the cpp
source.
Resolves GPU libc issues in #169983 and original issue: #166598
---------
Co-authored-by: shubhe25p <shubhp@mbm3a24.local>
Co-authored-by: Joseph Huber <huberjn@outlook.com>
This reverts commit 1327c50ef199b481f5326cf6ca3710fc111b70b1.
The printf headers are intended to be header-only, this introduces
external symbol dependencies.
Add support for %lc in printf by calling internal wcrtomb function and
relevant end-to-end sprintf test. Additionally, modified printf parser
for recognizing length modifier and added two internal error codes. Also
added a flag to disable wchar support on windows platform. Resolves
#166598
Co-authored-by: shubh@DOE <shubhp@mbm3a24.local>
This moves the libc-internal AllocChecker API out of
src/__support/CPP/new.h and updates CPP/README.md to state the
intent to keep src/__support/CPP and the LIBC_NAMESPACE::cpp
namespace a "pure" subset of standard C++ API polyfills.
[Previous commit had an incorrect default case when
FIND_FIRST_CHARACTER_WIDE_READ_IMPL was not specified in config.json.
This PR is identical to that one with one line fixed.]
As we implement more high-performance string-related functions, we have
found a need for better control over their selection than the big-hammer
LIBC_CONF_STRING_LENGTH_WIDE_READ. For example, I have a memchr
implementation coming, and unless I implement it in every variant, a
simple binary value doesn't work.
This PR makes gives finer-grained control over high-performance
functions than the generic LIBC_CONF_UNSAFE_WIDE_READ option. For any
function they like, the user can now select one of four implementations
at build time:
1. element, which reads byte-by-byte (or wchar by wchar)
2. wide, which reads by unsigned long
3. generic, which uses standard clang vector implemenations, if
available
4. arch, which uses an architecture-specific implemenation
(Reading the code carefully, you may note that a user can actually
specify any namespace they want, so we aren't technically limited to
those 4.)
We may also want to switch from command-line #defines as it is currently
done, to something more like
llvm-project/llvm/include/llvm/Config/llvm-config.h.cmake, and
complexity out of the command-line. But that's a future problem.
[This is more of a straw-proposal than a ready-for-merging PR. I got
started thinking about what this might look like, and ended up just
implementing something as a proof-of-concept. Totally open to other
methods an ideas.]
As we implement more high-performance string-related functions, we have
found a need for better control over their selection than the big-hammer
LIBC_CONF_STRING_LENGTH_WIDE_READ. For example, I have a memchr
implementation coming, and unless I implement it in every variant, a
simple binary value doesn't work.
This PR makes gives finer-grained control over high-performance
functions than the generic LIBC_CONF_UNSAFE_WIDE_READ option. For any
function they like, the user can now select one of four implementations
at build time:
1. element, which reads byte-by-byte (or wchar by wchar)
2. wide, which reads by unsigned long
3. generic, which uses standard clang vector implemenations, if
available
4. arch, which uses an architecture-specific implemenation
(Reading the code carefully, you may note that a user can actually
specify any namespace they want, so we aren't technically limited to
those 4.)
We may also want to switch from command-line #defines as it is currently
done, to something more like
llvm-project/llvm/include/llvm/Config/llvm-config.h.cmake, and
#including the resulting file, which would move quite a bit of
complexity out of the command-line. But that's a future problem.
#170525
Based on our
[RFC](https://discourse.llvm.org/t/rfc-libc-wctype-header-implementation/88941/10),
we are starting the implementation of the wctype header with C.UTF8
support. This implementation will increase the binary size by
approximately ~70KB, so this PR introduces a flag so that this is
configurable, allowing the user to choose between a simple ASCII
implementation or the full Unicode one.
Summary:
These were originally intended to represent the functions that are
present on the GPU as to be provided by the LLVM libc implementation.
The original plan was that LLVM libc would report which functions were
supported and then the offload interface would mark those as supported.
The problem is that these wrapper headers are very difficult to make
work given the various libc extensions everyone does so they were
extremely fragile.
OpenMP already declares all functions used inside of a target region as
implicitly host / device, while these headers weren't even used for CUDA
/ HIP yet anyway. The only things we need to define right now are the
stdio FILE types. If we want to make this work for CUDA we'd need to
define these manually, but we're a ways off and that's way easier
because they do proper overloading.
Closes#161461
- This is my first time contributing to libc's POSIX, so for reference I
used `clock_gettime` implementation for Linux. For convenience, here is
the description of `clock_settime` function
[behavior](https://www.man7.org/linux/man-pages/man3/clock_settime.3.html)
This patch adds the implementation for `inet_aton` function. Since this
function is not explicitly included in POSIX, I have marked it with
`llvm_libc_ext`. It is widely available and commonly used, and can also
be used to implement `inet_addr`, which is included in POSIX.
The VSCode instructions were stale from the transition to the runtimes
directory. This updates will all the options give on the Full Host Build
page.
Tested:
Built libc target.
Closes#159614
**Changes:**
- Initial implementation of rsqrt for single precision float
**Some small unrelated style changes to this PR (that I missed in my
rsqrtf16 PR):**
- Added extra - to the top comments to make it look nicer in
libc/shared/math/rsqrtf16.h
- Put rsqrtf16 inside of libc/src/__support/math/CMakeLists.txt in
sorted order
- Rearanged libc_math_function rsqrtf16 in Bazel to match alphabetical
order
This PR includes only one of the fxdivi functions (rdivi). It uses a
polynomial function for initial approximation followed by 4
newton-raphson iterations to calculate the reciprocal and finally
multiplies the numerator with it to get the result.
---------
Signed-off-by: Shreeyash Pandey <shreeyash335@gmail.com>
This patch enhances the GPU support documentation page (`support.html`)
by adding a new, detailed section for `math.h`. This new section
presents the results of the GPU math conformance tests, providing
quantitative data on the accuracy of the supported higher math
functions.
This is an implementation for template functions of localtime.
Update for this pull request: Implementation as been removed from this
pull request and will be added to a new one. This is because this pull
request is getting big. This pull request will only contain template
functions in order to implement localtime.
Update: The implementation is available in
https://github.com/zimirza/llvm-project/tree/localtime_implementation.
---------
Co-authored-by: Зишан Мирза <zmirza@tutanota.de>
Co-authored-by: Zishan Mirza <zmirza@posteo.de>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- scalbnbf16
- scalblnbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- totalorderbf16
- totalordermagbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- canonicalizebf16
- iscanonicalbf16
- fdimbf16
- copysignbf16
- issignalingbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- modfbf16
- remainderbf16
- remquobf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
Co-authored-by: OverMighty <its.overmighty@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- frexpbf16
- ilobbf16
- ldexpbf16
- llogbbf16
- logbbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- nearbyintbf16
- rintbf16
- lrintbf16
- llrintbf16
- lroundbf16
- llroundbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- getpayloadbf16
- setpayloadbf16
- setpayloadsigbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- nextafterbf16
- nextdownbf16
- nexttowardbf16
- nextupbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
Co-authored-by: OverMighty <its.overmighty@gmail.com>
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- fromfpbf16
- fromfpxbf16
- ufromfpbf16
- ufromfpxbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
Use LIBC_ERRNO_MODE_SYSTEM_INLINE instead as the default for the "public
packaging" (i.e. release mode) of an overlay build. The Bazel build has
already switched to use it by default in
5ccc734fa0355f971f8f515457a0bece33ab6642. This should be a safe change,
as LIBC_ERRNO_MODE_SYSTEM_INLINE works a drop-in (but simpler)
LIBC_ERRNO_MODE_SYSTEM replacement. Remove the associated code paths and
config settings.
Fixes issue #143454.
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.
