[PATCH] D146973: [Clang] Implicitly include LLVM libc headers for the GPU

Johannes Doerfert via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 27 18:42:40 PDT 2023


jdoerfert added a comment.

@sivachandra Host and device should agree on all ABI related properties of types or things turn badly, fast. That has to be a given for things to work, and from there, users expect types to be copyable, and usable on both sides.

@jhuber6 There are things we might need to define, sure. However, we can actually do that. If we do not use the host headers we can never support various things, like, no matter how much we try and want to. My examples with unused members inside of classes is one of them that is critical. We cannot tell people they can't use their objects because in the type is a subtype with a subtype with a subtype that has a different alignment/padding/size/layout on the host and device so every offset (read access) on one side will fail. We worked around issues in various headers already, this is expected to happen again as we include more host headers, but all of those problems are solvable by us, without requiring the user to modify arbitrarily complex parts of an existing codebase.
So far I've heard we need to define a `__ctype_b_loc`, and maybe a few other pointers like that. For one, that is doable, e.g., we also provide the right hooks to work with libgomp and other external libraries. The entire macro mess is actually a reason to use the host code since the user expects consistency. If it is a function here and a macro there, constexpr here and not constexpr there, ... will cause problems for people, and eventually us. Declaring a few compatibility pointers and functions seems a small price to pay.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146973/new/

https://reviews.llvm.org/D146973



More information about the cfe-commits mailing list