The docgen script was previously hardcoded to assume all implemented
macros must be placed in a *-macros.h header. This updates docgen to
read inline macro_value properties directly from the source YAML files,
correctly recognizing them as implemented.
Fix broken POSIX basedefs links for nested headers in llvm-libc docs.
The docgen script currently emits paths like `sys/wait.h.html`, but the
Open Group uses `sys_wait.h.html`, for example:
-
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_wait.h.html
This updates nested-header link generation while leaving flat headers
unchanged.
Add support for the half-precision complementary error function
`erfcf16``, using a Sollya generated polynomial implementation with
proper handling of special cases.
Extend the MPFR utilities with erfc support to allow tests.
closes: #180927
Clean up the `%public_api` printer code slightly - get rid of explicit
`\n` and ensure we only print `__BEGIN_C_DECLS` and `__END_C_DECLS` if
the generated header actually contains functions or objects to declare.
I've noticed that after 27ba9e2a44c11f8123528c350227db2c9a707c8f landed,
generated errno.h header has two blocks of `__BEGIN_C_DECLS` /
`__END_C_DECLS`: an empty one was generated automatically from
`%public_api` section that was intended to only add the `errno_t` type
declaration.
Updated LibcTest to handle Windows test executables:
* Added support for .exe extensions when identifying test executables.
* Skipped the executable bit check on Windows as it is not applicable.
* Updated .params file discovery to look for both <test>.exe.params and
<test>.params.
This allows running libc tests on Windows hosts.
This adds LIBC_CONF_PRINTF_MODULAR, which causes floating point support
(later, others) to be weakly linked into the implementation.
__printf_modular becomes the main entry point of the implementaiton, an
printf itself wraps __printf_modular. printf it also contains a
BFD_RELOC_NONE relocation to bring in the float aspect.
See issue #146159 for context.
closes#180171
part of #177259
Here are some extra changes apart from the usual which were needed
1. `libc/src/__support/FPUtil/generic/add_sub.h` → +0 -0 error
2. `libc/src/__support/FPUtil/generic/FMA.h` → implemented to handle
fmabf16(Normal,Normal,+/-INF)
```jsx
/home/runner/work/llvm-project/llvm-project/libc/test/src/math/fmabf16_test.cpp:62: FAILURE
Failed to match __llvm_libc_23_0_0_git::fmabf16(x, y, z) against LIBC_NAMESPACE::testing::mpfr::get_mpfr_matcher<mpfr::Operation::Fma>( input, __llvm_libc_23_0_0_git::fmabf16(x, y, z), 0.5, mpfr::RoundingMode::Nearest).
Input decimal: x: 338953138925153547590470800371487866880.00000000000000000000000000000000000000000000000000 y: 338953138925153547590470800371487866880.00000000000000000000000000000000000000000000000000 z: -inf
First input bits: 0x7F7F = (S: 0, E: 0x00FE, M: 0x007F)
Second input bits: 0x7F7F = (S: 0, E: 0x00FE, M: 0x007F)
Third input bits: (-Infinity)
Libc result: nan
MPFR result: -inf
Libc floating point result bits: (NaN)
MPFR rounded bits: (-Infinity)
```
1. ~~`libc/src/__support/FPUtil/bfloat16.h` → to handle *= operator for
Bfloat16 ( uses the already available mult operator)~~
moved to #182882
The exhaustive test currently includes subnormal range and for checking
for specific edge cases . This is due to the repeated failure at <2^32
input space specifically only for ubuntu 24.04 and 24.04-arm
The removed tests included -> PositiveRange and NegativeRange for
Normals and an extra positive test for subnormals/Denormals
Let me know if there are any changes expected or anything I missed in
this .
cc: @lntue @krishna2803 @overmighty
As far as I am aware, AOR is no longer used anywhere within LLVM, as
most of the required code has since been ported to elsewhere within the
project.
Removes the entire directory, and updates some now outdated comments.
Integration tests with ARGS or ENV in their add_integration_test() call
were being run with no arguments or environment variables by the
LibcTest lit format, causing failures in startup_args_test,
sprintf_size_test, getenv_test, execv_test, execve_test, and
getcwd_test.
Fix this by having add_integration_test() emit a sidecar
<executable>.params JSON file (via file(GENERATE)) whenever ARGS or ENV
are specified. LibcTest.execute() reads this file at test time and
passes the args and environment to the test executable.
Also always set PWD=exec_dir in the test environment so that
getenv("PWD") matches getcwd() for tests that compare them.
The lit-based test runner introduced in c776a52f only discovered
libc.test.src tests with a strict __unit__.__build__ or
__hermetic__.__build__ suffix. This missed four categories of tests:
1. libc.test.include.* tests (e.g. isnan_test, signbit_test)
2. libc.test.integration.* tests (e.g. pthread, unistd, startup)
3. libc.test.src.* tests that have no __unit__/__hermetic__ marker (e.g.
errno_test, dirent_test, htonl)
4. libc.test.src.* tests with extra option suffixes between the type
marker and .__build__ (e.g. __unit__.__NO_FMA_OPT.__build__)
Wire up the two missing build dependencies so that check-libc-lit builds
include and integration tests before running them, and update
_isTestExecutable() to recognise all four patterns.
The pattern documentation was consolidated into the _isTestExecutable()
docstring, where it is next to the code it describes, to avoid the two
diverging in future.
Tested:
Compared the test count from a full `ninja check-libc` run (2765 tests)
against `llvm-lit --show-tests libc/test` after this change and
confirmed the counts match exactly.
This provides optional lit-based test execution for the LLVM Libc tests,
alongside the existing CMake-based test execution.
Usage:
ninja -C build check-libc-lit
cd build && bin/llvm-lit libc/test/src/
Partially addresses
[#118694](https://github.com/llvm/llvm-project/issues/118694). A future
PR once this lands will flip the default (per suggestion in the RFC)
#170525
Previously, lookup tables were defined in a header so that they can be
constexpr, but this lead to each translation unit having it's own copy,
bloating the library size. Looking at current usages of wctype
functions, they are always used at runtime, so there's no benefit of
having them constexpr, so I'm moving them to a cpp file, so that there's
only a single copy in the library.
[#172040](https://github.com/llvm/llvm-project/issues/172040)
This patch implements the scripts for generating the lookup tables and
associated utils for wctype classification functions. Not all Unicode
properties are covered as not all need a lookup table, the rest will be
hardcoded. The size of the generated tables is 47,8KB.
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.
This makes the sorting behavior more uniform: functions and
macros are always sorted (separately), not only when merging.
This changes the sort order used for functions and other things
sorted by their symbol names. Symbols are sorted alphabetically
without regard to leading underscores, and then for identifiers
that differ only in the number of leading underscores, the fewer
underscores the earlier in the sort order. For the functions
declared in a generated header, adjacent names with and without
underscores will be grouped together without blank lines.
This is implemented by factoring the name field, equality, and
sorting support out of the various entity classes into a new
common superclass (hdrgen.Symbol).
This uncovered YAML's requirement to quote the string "NULL" to
avoid pyyaml parsing it as None (equivalent to Javascript null)
rather than a string.
This adds a few new features to hdrgen, all meant to facilitate
using it with inputs and outputs that are outside the llvm-libc
source tree.
The new `extra_standards` field is a dictionary to augment the
set of names that can be used in `standards` lists. The keys are
the identifiers used in YAML ("stdc") and the values are the
pretty names generated in the header comments ("Standard C").
This lets a libc project that's leveraging the llvm-libc sources
along with its own code define new APIs outside the formal and de
facto standards that llvm-libc draws its supported APIs from.
The new `license_text` field is a list of lines of license text
that replaces the standard LLVM license text used at the top of
each generated header. This lets other projects use hdrgen with
their own inputs to produce generated headers that are not tied
to the LLVM project.
Finally, for any function attributes that are not in a canonical
list known to be provided by __llvm-libc-common.h, an include
will be generated for "llvm-libc-macros/{attribute name}.h",
expecting that file to define the "attribute" name as a macro.
All this can be used immediately by builds that drive hdrgen and
build libc code outside the LLVM CMake build. Future changes
could add CMake plumbing to facilitate augmenting the LLVM CMake
build of libc with outside sources via overlays and cache files.
The JSON output support in hdrgen had a bug that tripped when
used with headers that use special-case headers like <stdint.h>
to supply some times, as well as llvm-libc-types/*.h headers.
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:
- bf16fma
- bf16fmaf
- bf16fmal
- bf16fmaf128
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
This PR adds implements following basic math functions for BFloat16 type
along with the tests:
- bf16add
- bf16addf
- bf16addl
- bf16addf128
- bf16sub
- bf16subf
- bf16subl
- bf16subf128
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
Reverts llvm/llvm-project#146226
The MPFR test uses `mpfr_asinpi` which requires MPFR 4.2.0 or later, but
the Buildbots are running an older version of MPFR.
See https://lab.llvm.org/buildbot/#/builders/104/builds/27743 for
example.
I said I was going to revert the PR until we have a workaround for older
versions of MPFR, but then I forgot and I just disabled the entrypoints
which doesn't fix the Buildbot builds.
The function is implemented using the following Taylor series that's
generated using [python-sympy](https://www.sympy.org/en/index.html), and
it is very accurate for |x| $$\in [0, 0.5]$$ and has been verified using
Geogebra. The range reduction is used for the rest range (0.5, 1].
$$
\frac{\arcsin(x)}{\pi} \approx
\begin{aligned}[t]
& 0.318309886183791x \\
& + 0.0530516476972984x^3 \\
& + 0.0238732414637843x^5 \\
& + 0.0142102627760621x^7 \\
& + 0.00967087327815336x^9 \\
& + 0.00712127941391293x^{11} \\
& + 0.00552355646848375x^{13} \\
& + 0.00444514782463692x^{15} \\
& + 0.00367705242846804x^{17} \\
& + 0.00310721681820837x^{19} + O(x^{21})
\end{aligned}
$$
## Geogebra graph
Closes#132210
This PR enables support for BFloat16 type in LLVM libc along with
support for testing BFloat16 functions via MPFR.
---------
Signed-off-by: krishna2803 <kpandey81930@gmail.com>
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
Co-authored-by: OverMighty <its.overmighty@gmail.com>
Summary:
There were a few issues with the first one, leading to some errors and
warnings. Most importantly, this was building on MSVC which isn't
supported.
Summary:
These tools `amdhsa-loader` and `nvptx-loader` are used to execute unit
tests directly on the GPU. We use this for `libc` and `libcxx` unit
tests as well as general GPU experimentation. It looks like this.
```console
> clang++ main.cpp --target=amdgcn-amd-amdhsa -mcpu=native -flto -lc ./lib/amdgcn-amd-amdhsa/crt1.o
> llvm-gpu-loader a.out
Hello World!
```
Currently these are a part of the `libc` project, but this creates
issues as `libc` itself depends on them to run tests. Right now we get
around this by force-including the `libc` project prior to running the
runtimes build so that this dependency can be built first. We should
instead just make this a simple LLVM tool so it's always available.
This has the effect of installing these by default now instead of just
when `libc` was enabled, but they should be relatively small. Right now
this only supports a 'static' configuration. That is, we locate the CUDA
and HSA dependencies at LLVM compile time. In the future we should be
able to provide this by default using `dlopen` and some API.
I don't know if it's required to reformat all of these names since they
used the `libc` naming convention so I just left it for now.
