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.
This fleshes out the <link.h> a little more, including the
`struct dl_phdr_info` type and declaring the dl_iterate_phdr
function. There is only a no-op implementation without tests, as
for the existing dlfcn functions.
Fixes incorrect logic that went unnoticed until the function was tested
with output and input types that have the same underlying floating-point
format.
Initial UEFI OS target support after the headers. This just defines
enough that stuff might try and compile. Test with:
```
$ cmake -S llvm -B build -G Ninja -DLLVM_RUNTIME_TARGETS=x86_64-unknown-uefi-llvm -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_ENABLE_RUNTIMES=libc -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_LIBC_FULL_BUILD=true -DCMAKE_C_COMPILER_WORKS=true -DCMAKE_CXX_COMPILER_WORKS=true -DLLVM_ENABLE_PROJECTS="clang;lld" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_LIBCXX=true -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-gnu -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-uefi-llvm -DCMAKE_INSTALL_LIBDIR=build/target/lib
$ ninja -C build
```
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:
This is done in preparation for making this header only so we can use it
without an object library. This will be a transient interface that
internal LLVM stuff with use. External people can use it too if they go
through the LLVM libc interface for shared stuff but there's no backward
compatibility guarantees.
Patch just cleans it up prior to the move.
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.
This involved a little bit of yak shaving because one of the new tests
depends on MPC, and we didn't have targets for it yet, so I ended up
needing to add a similar setup to what we have for MPFR.
`cpp::is_complex_type_same<T1, T2>` is a function, so we need
parentheses in order to call it. Otherwise the expression is treated
like a function pointer which is always true in this boolean context.
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.
This adds a feature to hdrgen to emit JSON summaries of header
files for build system integration. For now the summaries have
only the basic information about each header that is relevant for
build and testing purposes: the standards and includes lists.
Macros starting with alphabetic characters such as "LLVM" are in
the application name space and cannot be defined or used by a
conforming implementation's headers. This fixes the headers that
are entirely generated, and the __llvm-libc-common.h header to
use a conforming macro name for the header guard. That is, it
starts with "_LLVM_LIBC_" instead of "LLVM_LIBC_", as identifiers
starting with an underscore followed by a capital letter are in
the name space reserved for the implementation.
The remaining headers either will be fixed implicitly by removal
of their custom template files, or will need to be fixed by hand.
When the return type's rendering already doesn't end with an
identifier character, such as when it's `T *`, then idiomatic
syntax does not include a space before the `(` and arguments.
This allows a sort of "include" mechanism in the YAML files. A
file can have a "merge_yaml_files" list of paths (relative to the
containing file's location). These are YAML files in the same
syntax, except they cannot have their own "header" entry. Only
the lists (types, enums, macros, functions, objects) can appear.
The main YAML file is then processed just as if each of its lists
were the (sorted) union of each YAML file's corresponding list.
This will enable maintaining a single source of truth for each
function signature and other such details, where it is necessary
to generate the same declaration in more than one header.
This allows a YAML file to omit `template_header` and have no
`.h.def` file. A default template is generated based purely on
the information in the YAML file. This should handle most of the
cases. For now, it's exercised (aside from the hdrgen tests)
only for one of the simplest cases: <ctype.h>.
This includes making the parser notice the "standards" YAML field
at the top (header) level, not just in "functions" lists. The
standards listed for the header overall and for the individual
functions both feed into how a fully-generated header describes
itself in comments. To go with this, files using the default
generated template must stick to a new uniform set of spellings
for the "standards" lists. As more custom template files are
retired, the corresponding YAML files will need all their
standards lists normalized. For now, ctype.yaml is updated
with correct attribution for the POSIX `_l` extensions.
With this, the `types` list in YAML files should only be used to
list the types that a standard specifies should be in that header
per se. All the types referenced in function signatures will be
collected automatically.
This makes hdrgen emit `#include "..."` lines using the correct
relative path (number of `../` steps, if any) for the containing
header, and includes this in the sorted block of `#include` lines
also used for the macro headers.
A macro can specify macro_header instead of macro_value to
indicate that an llvm-libc-macros/ header file is supposed to
define this macro. This is used for dlfcn.h, which previously
bogusly redefined the RTLD_* macros to empty.
One of these days, we'll be able to specify time to a computer...
Also, POSIX can remove stuff all they want. Folks probably will continue to
depend on broken interfaces forever.
Link: #124654
Link: https://austingroupbugs.net/view.php?id=1330
This PR aims to add the groundwork to test the precision of libc complex
functions against MPC. I took `cargf` as a test to verify that the infra
works fine.
[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.
### 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.
This avoids touching the output file when it hasn't changed. The
cmake build integration now uses this so that touching a .yaml or
.h.def file in ways that don't affect the generated header output
won't cause unnecessary recompilations.
