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

> On Nov 29, 2021, at 12:54, Philip Reames via llvm-dev <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.

-Matt

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

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>