yaxunl added a comment. In D82087#2146170 <https://reviews.llvm.org/D82087#2146170>, @sameerds wrote:
> >> https://github.com/ROCm-Developer-Tools/HIP/blob/master/docs/markdown/hip_kernel_language.md#warp-vote-and-ballot-functions > > > > I think if the language interface insists on fixing the wave size, then I > > think the correct solution is to implement this in the header based on a > > wave size macro (which we're desperately missing). The library > > implementation should be responsible for inserting the extension to 64-bit > > for wave32 Agree that FE should have a predefined macro for wave front size. Since it is per amdgpu target and not per language, it should be named as __amdgpu_wavefront_size__ or something similar, then it could be used by all languages. Then we need to initialize warpSize in HIP header by this macro https://github.com/ROCm-Developer-Tools/HIP/blob/386a0e0123d67b95b4c0ebb3ebcf1d1615758146/include/hip/hcc_detail/device_functions.h#L300 I tends to think we should define __ballot in HIP header conditionally by the wavefront size so that the return type is correct for both wave32 and wave64 mode. We should assume normal HIP compilation always have -mcpu specified so that wavefront size is known at compile time. If -mcpu is not specified probably we should not define warpSize or __ballot. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82087/new/ https://reviews.llvm.org/D82087 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits