hliao added a comment. In D80237#2051918 <https://reviews.llvm.org/D80237#2051918>, @rjmccall wrote:
> In D80237#2051909 <https://reviews.llvm.org/D80237#2051909>, @hliao wrote: > > > In D80237#2051887 <https://reviews.llvm.org/D80237#2051887>, @rjmccall > > wrote: > > > > > `addrspacecast` might be a real conversion. I feel like this is really > > > going well beyond what argument coercion should be expected to do, and we > > > need to step back and re-evaluate how we're doing this. > > > > > > `addrspacecast` *must* be a no-op in terms of argument coercion. > > > So what does this mean exactly? If the ABI lowering uses argument coercion > in a way that changes address spaces, it must ensure that the representations > are different? So it's always *legal* to just do a memcpy here, we're just > trying really hard to not do so. If `addrspacecast` is used, the target must ensure that `addrspacecast` would NOT change the representation to use argument coercion. Yeah, it's always safe to memcpy or load/store directly but, without target specific knowledge, SROA/GVN won't create a no-op `addrspacecast` to help address space inferring pass. SROA/GVN only generates the pair of `ptr2int`/`int2ptr` to ensure the presentation is the same. Unfortunately, address space inferring doesn't understand that without target specific knowledge as well. That leaves the address space information won't be propagated to final IR. We need a trigger to enable that. That's why we need to add `addrspacecast` for a simple type argument in line 1314 - 1321. In this patch, we need to traverse the struct and add proper `addrspacecast`. 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