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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
