It's purely device code, so it doesn't need HIP's defining feature of generating both host and device code. It can be just C code that happens to be compiled to the AMDGPU target.
The flags are taken from the users/benvanik/amdgpu branch, build_tools/cmake/iree_amdgpu_library.cmake.
The old code used to avoid -O3 on RDNA3 due to numerical correctness issues. Based on what we know at this point about RDNA3, numerical correctness issues are to be expected on RDNA3 and we should not refrain from -O3, instead we should relax test tolerance on RDNA3 as needed.
Types changes:
Input buffers used to be passed as (non-const) T*, changed to const T*.
Size parameters were passed as size_t. I thought let's not have a size type in AMDGPU ukernels, where we are dealing with multiple address spaces with different pointer widths - let's be explicit. Then the direct mapping of size_t would be uint64_t (given this is global address space), but see next point:
Switched from unsigned to signed sizes. Generally, unsigned sizes (as in size_t) is a legacy choice that we don't have to be bound to here, given the self-containedness of this ukernel code. And in the context of lowering MLIR to ukernel calls, the typical MLIR values that would lower to these sizes are of MLIR index type, and while that is signless, it is more often treated as signed than unsigned.
It's purely device code, so it doesn't need HIP's defining feature of generating both host and device code. It can be just C code that happens to be compiled to the AMDGPU target.
The flags are taken from the
users/benvanik/amdgpubranch,build_tools/cmake/iree_amdgpu_library.cmake.Tested with:
Notes:
-O3on RDNA3 due to numerical correctness issues. Based on what we know at this point about RDNA3, numerical correctness issues are to be expected on RDNA3 and we should not refrain from -O3, instead we should relax test tolerance on RDNA3 as needed.const)T*, changed toconst T*.size_t. I thought let's not have a size type in AMDGPU ukernels, where we are dealing with multiple address spaces with different pointer widths - let's be explicit. Then the direct mapping ofsize_twould beuint64_t(given this is global address space), but see next point:size_t) is a legacy choice that we don't have to be bound to here, given the self-containedness of this ukernel code. And in the context of lowering MLIR to ukernel calls, the typical MLIR values that would lower to these sizes are of MLIRindextype, and while that is signless, it is more often treated as signed than unsigned.