arsenm added a comment. In D79744#2030294 <https://reviews.llvm.org/D79744#2030294>, @rjmccall wrote:
> The parameter variable is formally considered to be in a particular address > space, and taking the address of it yields a pointer in that address space. > That can only work for an indirect argument if either (1) the address space > of the pointer that's actually passed can be freely converted to that formal > address space (because it's a subspace, or because it's a superspace but > known to be in the right subspace) or (2) we're willing to copy the object > into the right address space on the callee side (and able to — obviously this > only works for POD types). I do see the merit of allowing an address space > to be specified for targets that consider locals to be in a different formal > address space than the stack would naturally be (e.g. a generic address > space); I don't remember if that applies to AMDGPU. Kernel arguments aren't directly visible to the user program, so this is an implementation detail. The user variable is the alloca that we need to explicitly copy to as you mentioned, which this patch does. It's possible to poke at these through intrinsics, but the kernel address space isn't part of the language. POD type or not, we're going to have to do something to unload values from the constant buffer onto the stack. > `byval` in LLVM is not a generic "this is a by-value argument" annotation; it > specifically means that the value is actually passed on the stack despite the > formally indirect convention, and therefore there's an implicit memcpy on the > caller side. That is why `byval` is inherently tied to the `alloca` address > space: there's no actual pointer being passed, so it doesn't make sense to > pretend it might have been promoted into a different address space. That is > also why there is no restriction to writing into the pointer: there's no > reason to prevent writing to the argument slot. In this case there is never a call. Only the callee read exists as this is the entry point. What would the alternative be? Add another flavor of byval attribute that's nearly identical? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79744/new/ https://reviews.llvm.org/D79744 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
