[PATCH] D79744: clang: Add address space to indirect abi info and use it for kernels

Tue Jun 2 11:32:30 PDT 2020

arsenm added a comment.

In D79744#2047788 <https://reviews.llvm.org/D79744#2047788>, @jdoerfert wrote:

> In D79744#2047482 <https://reviews.llvm.org/D79744#2047482>, @arsenm wrote:
>
> > For the purpose here, only the callee exists. This is essentially a freestanding function, the entry point to the program. There is no caller function, and in the future I would like to make a call to amdgpu_kernel an IR verifier error (technically OpenCL device enqueue is an exception to this, but we don't treat this as a call. Instead there's a lot of library magic to invoke the kernel. From the perspective of the callee nothing changes, since it's still not allowed to modify the incoming argument buffer or aware it was called this way).
>
>
> Did you consider callback annotation for the device enqueue call? While that might not change anything *now*, I'm expecting interesting optimization opportunities there at some point "soon".

I'm not sure what you mean by this exactly. I'm assuming this means "move device enqueue implementation into the backend". I don't know all the details of how device enqueue is implemented, but there's so much code in the library to support this, I don't think this would end up looking like a normal calling convention lowering. It would guess it would end up looking like an IR pass that would need a calling convention with this restriction, and then a pass to insert the code the library uses now.

> 
> 
>> The load-from-constant nature needs to be exposed earlier, so I think this necessarily involves changing the convention lowering in some way and it's just a question of what it looks like. To summarize the 2.5 options I've come up with are
>> 
>> 1. Use constant byval parameters, as this patch does. This requires the least implementation effort but doesn't exactly fit in with byval as defined.
> 
> And, as was noted in the `byval` lang ref patch (D79636 <https://reviews.llvm.org/D79636>), there is a reasonable argument to be made to phase-out `byval` in favor of some explicit copying. If that happens, this solution should not be "the last `byval` user". Also, `byval` arguments could be used as scratchpad by smart optimizations. I somehow don't believe this is a great choice but I can by now see that the others are neither.

I assume this would need replacement with a slew of other attributes to capture the type/size/alignment/dereferencability, or a new attribute entirely?

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79744/new/

https://reviews.llvm.org/D79744