aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
diff options
context:
space:
mode:
authorNick Desaulniers <nickdesaulniers@users.noreply.github.com>2024-04-11 10:11:58 -0700
committerGitHub <noreply@github.com>2024-04-11 10:11:58 -0700
commitf626a35086d90f25986e3f06e01a54cca91250d8 (patch)
tree33c399a67324e2bbf39ffe228e3f36685d768881 /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
parent5122a2c2320c7b14f6585e63b7fc43ac82a550c2 (diff)
downloadllvm-f626a35086d90f25986e3f06e01a54cca91250d8.zip
llvm-f626a35086d90f25986e3f06e01a54cca91250d8.tar.gz
llvm-f626a35086d90f25986e3f06e01a54cca91250d8.tar.bz2
[libc] Codify header inclusion policy (#87017)
When supporting "overlay" vs "fullbuild" modes, "what ABI are you using?" becomes a fundamental question to have concrete answers for. Overlay mode MUST match the ABI of the system being overlayed onto; fullbuild more flexible (the only system ABI relevant is the OS kernel). When implementing llvm-libc we generally prefer the include-what-you use style of avoiding transitive dependencies (since that makes refactoring headers more painful, and slows down build times). So what header do you include for any given type or function declaration? For any given userspace program, the answer is straightforward. But for llvm-libc which is trying to support multiple ABIs (at least one per configuration), the answer is perhaps less clear. This proposal seeks to add one layer of indirection relative to what's being done today. It then converts users of sigset_t and struct epoll_event and the epoll implemenations over to this convention as an example.
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions