[llvm-dev] [RFC] : LLVM IR should allow bitcast between address spaces with the same size

[Matt Arsenault via llvm-dev]

> On Nov 29, 2021, at 13:28, Philip Reames <listmail at philipreames.com> wrote:
> 
> 
> 
> On 11/29/21 10:19 AM, Matt Arsenault wrote:
>> 
>> 
>>> On Nov 29, 2021, at 12:54, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> Strong -1 here.  This seems like an abuse of bitcast to avoid nailing down interfaces and semantics for restricted address space casts.  IMO, we should not accept the proposed IR change and should instead work on standardizing APIs/semantics for restricted addrspacecasts.  
>> 
>> I think you are misunderstanding the point of the change. The motivating example is specifically not an address space cast. The reason to do this is not to improve the optimization of no-op address space casts, although that is a potential side effect. The point is to give the IR a way to represent a cast we know is a no-op cast to represent type punning in the original program without resorting to ptrtoint/inttoptr. This is to avoid the pessimization of ptrtoint, not to make no-op addrspacecast optimizations better.
> My counter proposal would be: use an addrspacecast for the cast.  Have GVN insert an addrspacecast instead of ptrtoint/inttoptr.  
> 
> From GVNs perspective, type punning *implies* that the resulting addrspacecast must be mustalias.  It doesn't have to explicitly query anything to prove that.  One thing to highlight: Two pointers in different addrspaces can be mustalias *without* sharing the same bit pattern.  As a result, the GVN case implies mustalias, but *not* pointer equality.  
> 
> (I forget where we stand on whether addrspacecast is allowed to fault.  If we allow faults, we need a semantic restriction on introducing the addrspacecast, but that's simply a target property check.  I vaguely think we don't allow addrspacecast to fault, and thus this aside is irrelevant.)
> 
> For the nop case (e.g. where the bits are the same), add a TTI hook, and teach ComputeKnownBits and other analyzes to selectively look back through them.
This still forces adding more target information into places where it does not belong, Additionally, this is still no help if the given pair of address spaces is not a no-op. We would still have to fallback to the ptrtoint/inttoptr pair, so there’s still a semantic hole in the IR that requires introducing them

-Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211130/1360154a/attachment.html>