llvm dev - Oct 2020 - Alias Analysis roundtable - minutes

Thanks everybody for attending the Alias Analysis roundtable !



The minutes can be found here:
https://docs.google.com/document/d/1kXauIBnrI73sgWi8tLK4rXwfTDvdG1wVy7Z554Mt1H0/edit

and also below.



Greetings,



Jeroen Dobbelaere

--



Things discussed:

  *   Fortran and !noalias, !alias.scope and scalability:

     *   Using the llvm.noalias with unique objectId might help in compressing
the information. Experiment not done yet
  *   ptr_provenance: optional operand, mandatory operand or operand bundles ?
     *   Current implementation has an optional operand that always takes space
(for load/store instructions). Impact on speed is only for load/store
instructions.
When the ptr_provenance operand is not there, the original pointer is used for
provenance.
     *   llvm.noalias.arg.guard %ptr, %ptr_prov
Is used to merge a pointer value with its provenance. This is used when passing
as argument, storing to memory, returning from function
     *   Ptr_provenance info is not used to decide on 'pointer
comparison'. The c++ standard might need an update to allow this (?)
  *   Comparable to 'base pointer' ? probably not completely the same.
  *   inttoptr/ptrtoint casts, sroa


All help with reviewing the patches is welcome ! The first one, provides the
documentation on the implemented mechanism. https://reviews.llvm.org/D68484



Join us on the 4-weekly LLVM Alias Analysis Call. Meeting info:

https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit#heading=h.vpxs8lkuxy79


-----

Notes in the 'chat':
>From Me to Everyone:  08:58 PM
https://docs.google.com/document/d/1kXauIBnrI73sgWi8tLK4rXwfTDvdG1wVy7Z554Mt1H0/edit
>From John Reagan to Everyone:  09:07 PM
Our proprietary code generator for Alpha/Itanium has a "base pointer"
for such loads in our IR which provides the equivalent of your provenance for
alignment
>From Jason Eckhardt to Everyone:  09:17 PM
please mute if not speaking-- hearing extraneous noise
>From John Reagan to Everyone:  09:18 PM
Our old CG also has an explicit 'basedref' IR tuple that can provide
additional alignment, based-on, etc. info.
>From Roman Lebedev to Everyone:  09:20 PM
loss of inttoptr-ptrtoint casts is mostly bug, i think it will be resolved
sadly there are more places where we introduce inttoptr(load), e.g. because
instcombine expands memcpy
>From Matt Arsenault to Everyone:  09:25 PM
Need to allow no-op bitcasts between same sized address spaces to avoid one
place we interpret ptrtoint/inttoptr pairs
>From John Reagan to Everyone:  09:25 PM
Yes, it has worked well. I can discuss elsewhere if interested
>From John Reagan to Everyone:  09:26 PM
Yes, it has worked well. I can discuss elsewhere if interested
Perfect.  I'll watch for that.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201006/3045c0e8/attachment.html>