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

[Philip Reames via llvm-dev]

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.

Philip


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211129/a35484da/attachment-0001.html>