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.
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.
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.
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.
Implements the posix-specified strftime conversions for the default
locale, along with comprehensive unit tests. This reuses a lot of design
from printf, as well as the printf writer.
Roughly based on #111305, but with major rewrites.
By far the most important part of this patch is updating
GettingInvolved.rst to include the invite link, but I've grepped for any
other discord.com links.
I'm no Discord expert, but from my experience (confirmed via @preames
kindly testing as well) the direct channel links provide a confusing
experience if you haven't already found and used an invite link to the
LLVM Discord server. If you're logged into Discord but not a member of
LLVM's sever, the web app opens and then...nothing. No channel opens, no
prompt to join the server or even a hint that you need to find an invite
link (and if you're not used to Discord, you likely don't even know
that's necessary).
This patch addresses the issue by providing the invite link where
Discord is mentioned.
This reverts commit bada9220b87e73c0f4a498b82f883e17eda928d1.
Revert "[libc][stdfix] Implement fixed point `countlsfx` functions in llvm-libc (#125356)"
This reverts commit f2a1103b323492160d7d27a1575fbda709b49036.
The existing options for bin→dec float conversion are all based on the
Ryū algorithm, which generates 9 output digits at a time using a table
lookup. For users who can't afford the space cost of the table, the
table-lookup subroutine is replaced with one that computes the needed
table entry on demand, but the algorithm is otherwise unmodified.
The performance problem with computing table entries on demand is that
now you need to calculate a power of 10 for each 9 digits you output.
But if you're calculating a custom power of 10 anyway, it's easier to
just compute one, and multiply the _whole_ mantissa by it.
This patch adds a header file alongside `float_dec_converter.h`, which
replaces the whole Ryū system instead of just the table-lookup routine,
implementing this alternative simpler algorithm. The result is accurate
enough to satisfy (minimally) the accuracy demands of IEEE 754-2019 even
in 128-bit long double. The new float128 test cases demonstrate this by
testing the cases closest to the 39-digit rounding boundary.
In my tests of generating 39 output digits (the maximum number supported
by this algorithm) this code is also both faster and smaller than the
USE_DYADIC_FLOAT version of the existing Ryū code.
Summary:
This introduces libc cache files and adds one for building the GPU
support. The cache files will set defaults for these arguments which can
be overridden if the user needs to. They also serve as documentation for
how the builid is expected to look.
[libc][docs] add cpio to documentation and include related functi…
These changes ensure that the cpio header is documented properly
with respect to the issue
(https://github.com/llvm/llvm-project/issues/122006 ).
**Changes:**
1. **cpio.yaml**: Created a new YAML file for cpio with functions
and related macros.
2. **CMakeLists.txt**: Added cpio to the documentation
directories.
3. **index.rst**: Included `cpio` in the documentation index.
---------
Co-authored-by: siya <siya@Siya.com>
These changes ensure that the `sys/wait` header is documented properly
with respect to the issue (#122006 ).
**Changes:**
1. **wait.yaml**: Created a new YAML file for `sys/wait` with functions
(`wait`, `waitid`, `waitpid`) and related macros.
2. **CMakeLists.txt**: Added `sys/wait` to the documentation
directories.
3. **index.rst**: Included `sys/wait` in the documentation index.
This commit does a few things, with the intent to make it more straightforward
to potential future users how to get started with llvm-libc. Answers to "What's
the status and how do I use it?" are front and center, "above the fold."
This commit does a few things:
* reorganize the landing page's toctree: start with implementation status, arch
* support, platform support, and
compiler support.
* Then a (new) simple getting started page using full host builds. Then more
* Advanced topics such as host vs cross builds, overlay mode,
gpu builds and additional configuration options.
* Remove c23 status, the old fullbuild_mode landing page, and
usage_modes landing pages. c23 status isn't as interesting as I originally
thought it might.
We should point people at full host builds to start, then link to more info on
cross compilation, or overlay mode as more advanced topics. I assert most users
starting out won't care about those.
### Add sys/resource header's implementation status ( #122006 )
#### Changes:
1. **CMakeLists.txt**: Added `sys/resource` to the list of documentation
directories.
2. **index.rst**: Included `sys/resource` in the documentation index.
3. **resource.yaml**: Created a new YAML file for `sys/resource` with
functions and macros which manages system resources.
This PR adds documentation support for the `sys/resource` header,
including functions and macros as per the latest POSIX standards.
This pull request introduces the following changes to the project with
reference to issue ( #122006 ):
1. **Documentation Update**:
- Added a new YAML file `if.yaml` under `net` to document network
interface functions and macros.
- The `if.yaml` file includes the following functions and macros:
- Functions:
- `if_freenameindex`
- `if_indextoname`
- `if_nameindex`
- `if_nametoindex`
- Macros:
- `IF_NAMESIZE`
2. **CMake Configuration Update**:
- Updated the `CMakeLists.txt` file to create the necessary directory
for the `net` headers.
- Included the `net/if` documentation in the Sphinx build configuration.
3. **Index Update**:
- Updated the `index.rst` file to include a reference to the newly added
`net/if` documentation.
**Purpose**:
- This pull request adds documentation for network interface functions
and macros, ensuring they are included in the project's documentation.
- Updates the CMake configuration to support the new documentation.
**Testing**:
- Verified that the new YAML file is correctly referenced in the
`index.rst`.
- Ensured that the documentation builds without errors and includes the
new network interface documentation.
Co-authored-by: Nick Desaulniers <ndesaulniers@google.com>
This pull request introduces the following changes to the project with
reference to ( #122006 ):
1. **Documentation Update**:
- Added a new YAML file `in.yaml` to document network protocol and
address macros.
- The `in.yaml` file includes the following macros:
- `IPPROTO_IP`
- `IPPROTO_IPV6`
- `IPPROTO_ICMP`
- `IPPROTO_RAW`
- `IPPROTO_TCP`
- `IPPROTO_UDP`
- `INADDR_ANY`
- `INADDR_BROADCAST`
- `INET_ADDRSTRLEN`
- `IPV6_JOIN_GROUP`
- `IPV6_LEAVE_GROUP`
- `IPV6_MULTICAST_HOPS`
- `IPV6_MULTICAST_IF`
- `IPV6_MULTICAST_LOOP`
- `IPV6_UNICAST_HOPS`
- `IPV6_V6ONLY`
- `IN6_IS_ADDR_UNSPECIFIED`
- `IN6_IS_ADDR_LOOPBACK`
- `IN6_IS_ADDR_MULTICAST`
- `IN6_IS_ADDR_LINKLOCAL`
- `IN6_IS_ADDR_SITELOCAL`
- `IN6_IS_ADDR_V4MAPPED`
- `IN6_IS_ADDR_V4COMPAT`
- `IN6_IS_ADDR_MC_NODELOCAL`
- `IN6_IS_ADDR_MC_LINKLOCAL`
- `IN6_IS_ADDR_MC_SITELOCAL`
- `IN6_IS_ADDR_MC_ORGLOCAL`
- `IN6_IS_ADDR_MC_GLOBAL`
_I believe, all these macros are necessary and should be documented._
2. **CMake Configuration Update**:
- Updated the `CMakeLists.txt` file to create the necessary directory
for the `netinet` headers.
- Included the `netinet/in` documentation in the Sphinx build
configuration.
3. **Index Update**:
- Updated the `index.rst` file to include a reference to the newly added
`netinet/in` documentation.
**Purpose**:
- This pull request adds documentation for network protocol and address
macros in the `netinet/in` header.
- Updates the CMake configuration to support the new documentation.
**Testing**:
- Verified that the new YAML file is correctly referenced in the
`index.rst`.
- Ensured that the documentation builds without errors and includes the
new network interface documentation.
This pull request ensures that the `netinet/in` header macros are
documented and included in the project's documentation, and updates the
CMake configuration to support these changes.
Now, `ninja docs-libc-html` will re-run docgen.
Previously, we would run docgen offline, and commit the result.
Now we no longer need to do that; docgen is invoked from the
dependencies of the `docs-libc-html` target on demand. This
commit removes the dynamically generated .rst files (keeping
the static ones that haven't been converted to docgen), and
fixes up some mistakes I failed to cleanup recently since I
didn't have such automation in place to catch such bugs.
The .yaml files should live next to the corresponding .h.def
files in libc/include/, rather than next to the implementation of
the tool in libc/utils/hdrgen/. As with the .h.def files, there
is no need for a yaml/ subdirectory under include/. This simpler
layout is more natural for maintenance and also simplifies build
integration outside the LLVM CMake build.
