| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[Clang] Gut the libc wrapper headers and simplify (#168438) 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. | 8 个月前 | |
[libc][hdrgen] Sort identifiers with leading underscores specially (#165745) 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. | 9 个月前 | |
[libc] Move hdrgen into utils/ subdirectory (#121256) | 1 年前 | |
[libc] clean up the hdrgen docs a bit (#121974) Since the files have been reorganized, the readme is out of date. This patch updates it to be more accurate. | 1 年前 | |
[libc][hdrgen] Allow to treat hdrgen Python code as a Python module. (#128955) 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. | 1 年前 | |
[libc][hdrgen] Allow to treat hdrgen Python code as a Python module. (#128955) 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. | 1 年前 |
This directory also contains the Python sources for hdrgen, which is
what generates the headers public libc headers. The definitions for these
headers are in the include directory. The .h.def files are the bases
and the .yaml files are the contents.