yxsamliu wrote: > > how does a user initialize/populate this type of objects? by calling a > > builtin function? > > yes. The builtin functions will come next. > > > need a SemaCUDA test to make sure it is defined with %clang_cc1 -triple > > x86_64-unknown-gnu-linux -aux-triple amdgcn-amd-amdhsa , like > > https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCUDA/builtin-mangled-name.cu > > Why do we need this to be defined in that way? This should only be used in > kernel. I purposely made the type available only when the target triple is > amdgcn. @yxsamliu
HIP is single source program, meaning the same source code is visible to both device compilation and host compilation. If you have code that only compiles in device compilation, you have to put `#if __HIP_DEVICE_COMPILE__ #endif` around it. That would clutter the program. The difference between source code seen in device compilation and host compilation also increases the risk of violation of one-definition-rule. Therefore, in general, we request types, function declarations/definitions and pre-defined macros to be visible to both device and host compilation. This is true to the existing amdgcn builtin functions. Due to the mechanism already in place about -aux-triple, we see device builtin functions in current host compilation, otherwise, HIP programs will be cluttered with `#if __HIP_DEVICE_COMPILE__ #endif` everywhere. We just request the newly added builtin type to follow this existing convention. https://github.com/llvm/llvm-project/pull/94830 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
