[llvm-dev] Alias Analysis roundtable - minutes

Jeroen Dobbelaere via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 6 12:53:21 PDT 2020

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.


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:



Notes in the 'chat':

>From Me to Everyone:  08:58 PM


>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>

More information about the llvm-dev mailing list