[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.
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>
More information about the llvm-dev
mailing list