Jeroen Dobbelaere via llvm-dev
2020-Oct-06 19:53 UTC
[llvm-dev] 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 PMhttps://docs.google.com/document/d/1kXauIBnrI73sgWi8tLK4rXwfTDvdG1wVy7Z554Mt1H0/edit>From John Reagan to Everyone: 09:07 PMOur 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 PMplease mute if not speaking-- hearing extraneous noise>From John Reagan to Everyone: 09:18 PMOur 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 PMloss 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 PMNeed 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 PMYes, it has worked well. I can discuss elsewhere if interested>From John Reagan to Everyone: 09:26 PMYes, 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>