jhuber6 wrote: > I am afraid this will break all existing CUDA/HIP programs since they expect > to be able to parse the builtins for both host and device targets. > > In the spirit of single source, the compiler sees the entire code for all > targets, including host target and all device targets. It is supposed to have > AST for all host and device targets. Ideally, it should generate a > heterogeneous IR that is for all host and device targets, and eventually > generate a heterogeneous executable that includes everything. That would make > some optimizations across host and device IR possible. It is just due to > current limitation of LLVM/Clang, we generate and process IR separately for > each host and device target. > > I think at least during parsing/sema/AST clang could and should see code and > AST for both host and device, since that helps avoid inconsistency between > host and device. Therefore it is necessary to see builtins for both host and > device. Clang only needs to make sure they are only emitted for the supported > target.
I'm curious what would break, since I cannot imagine a single situation where someone would use `__has_builtin` and not immediately use said builtin. The current behavior makes this unusable in a device context. There's already ways to split the host/device compiles via the preprocessor (i.e. `__HIP_DEVICE_COMPILE__` or `__CUDA_ARCH`) and it's pretty much baked into the CUDA compilation pipeline, and by extension HIP. Other languages like OpenMP and SYCL skirt around the idea, seeking to put these things into the AST instead of the processor, so it's more of an implementation detail there. People can already use the preprocessor to emit different code depending on the target architecture, I don't see how this is any different. It's important that both sides match up as much as possible so things like sizes of structs are coherent, but I really don't see this case breaking anything more than it already is. https://github.com/llvm/llvm-project/pull/121839 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
