rjmccall added a comment. In D80237#2062991 <https://reviews.llvm.org/D80237#2062991>, @arsenm wrote:
> In D80237#2058108 <https://reviews.llvm.org/D80237#2058108>, @rjmccall wrote: > > > 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. > > > Yes, there's no valid way to pass a non-global address space pointer through > a flat pointer into a kernel. This doesn't apply in other contexts Okay. And you can't just treat kernel parameters specially in your pass that un-promotes generic pointers back to global pointers? Or is that pass not quite so precise as that? 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
