skc7 wrote:
> Thanks for this, the AMDGPU wiring looks good to me and I'm not trying to
> block it. I had a couple of questions about follow-ups.
>
> Since `-fclangir-call-conv-lowering` is on by default, routing the amdgpu
> triple here means a few common patterns that compile on main today would now
> hit the NYI error:
>
> * Kernel arguments that are multi-field structs (`IndirectAliased`). This
> includes every SYCL kernel on AMDGPU, since the kernel object is a struct,
> which is why `kernel-caller-entry-point.cpp` needed
> `-fno-clangir-call-conv-lowering`.
> * Device-function aggregates of 33–64 bits, e.g. `struct { int a, b; }`,
> which the classifier coerces to `[2 x i32]` (no array case in `abiTypeToCIR`
> yet).
> * Non-trivial C++ records passed indirectly in addrspace(5).
>
> Are you planning to follow up on these soon? If it'll take a while, would you
> be open to keeping the `target=amdgpu` pass option and the cir-opt tests
> here, but holding off on the automatic triple mapping in `CIRPasses.cpp`
> until byref/array coercion land? Either way works for me. I mostly want to
> make sure SYCL/HIP on AMDGPU through CIR doesn't regress in the meantime.
>
> One related note for when `IndirectAliased` gets supported: for HIP kernel
> structs that contain generic pointers, classic codegen coerces the pointers
> to global and passes the struct direct (the `LTy == OrigLTy`), while the LLVM
> ABI library always returns byref. That would become a silent ABI mismatch
> rather than an error, so it might be worth a FIXME/issue now. The TODO in the
> kernel-args test already hints at it.
Thanks for the suggestion. Agreed. Instead of regressing SYCL/HIP on AMDGPU on
main, I have moved the triple mapping and clang tests to follow-up PR: #233822,
stacked on this one. This PR now only adds `target=amdgpu` to the pass with
cir-opt tests.
I'm working on fixes for the NYI cases. Will only merge #233822 once fixes are
in place.
https://github.com/llvm/llvm-project/pull/220197
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
