[PATCH] D80237: [hip] Ensure pointer in struct argument has proper `addrspacecast`.

Wed May 27 13:02:44 PDT 2020

rjmccall added a comment.

In D80237#2055902 <https://reviews.llvm.org/D80237#2055902>, @arsenm wrote:

> In D80237#2051933 <https://reviews.llvm.org/D80237#2051933>, @rjmccall wrote:
>
> > Okay.  Can you explain why we need to coerce in the first place, though?  Especially if the representation is the same, why is your target-lowering requiring parameters to be coerced to involve pointers in a different address space?
>
>
> It's not a requirement, but an optimization. The pointer representation is the same, but there's a penalty to using the generic pointer. From the language context here, we know the flat pointer can never alias the non-global address spaces.

Is that because it's a kernel argument?  I don't understand how the coercion can work in general for structs that just contain pointers.

> I think the real problem here is the IR is missing a no-op cast between pointers with different address spaces. With the current promotion, GVN sees the bits of the addrspace(0) ptr get reinterpreted as addrspace(1), and doesn't have a better option than a ptrtoint/inttoptr pair. When addrspacecast was added, pointer bitcasts between different address spaces were disallowed (I think mostly for reasons that no longer apply). If we reallowed pointer bitcast between equivalent sized address spaces as known no-op cast, we wouldn't need to change the argument promotion in the frontend.

That seems like it would be a much cleaner way of handling this, yeah.  Ideally, GVN would be able to find the target-specific information necessary to know that it can introduce an `addrspacecast` between two address spaces.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80237