<html><body><p><font size="2">Hi Hal,</font><br><br><font size="2"> If it is okay with the group, we can start looking into the LLVM codebase for Metadata operations and discuss about the technical details related to the scalability. In that case, we can start with the following.</font><br><font size="2"> </font><br><tt><font size="2"> ./llvm/include/llvm/IR/Metadata.h</font></tt><br><tt><font size="2"> ./llvm/lib/IR/Metadata.cpp</font></tt><br><tt><font size="2"> ./llvm/lib/Analysis/ScopedNoAliasAA.cpp</font></tt><br><font size="2"> </font><br><font size="2"> If needed, we can present some slides for a quick recap of the alias representation.</font><br><font size="2"> </font><br><font size="2"> Regarding the hierarchical representation, we can start with your patch for scoped-noalias metadata.</font><br><font size="2"> </font><a href="https://github.com/llvm/llvm-project/commit/9414665a3b0bd525f84d76e24048ca60ebe6c710"><font size="2">https://github.com/llvm/llvm-project/commit/9414665a3b0bd525f84d76e24048ca60ebe6c710</font></a><br><font size="2"> </font><br><font size="2">Regards,</font><br><font size="2">Tarique Islam<br>XL Fortran Compiler Development<br>IBM Toronto Software Lab<br>tislam@ca.ibm.com (905) 413-3190<br><br></font><br><br><img width="16" height="16" src="cid:1__=8FBB0FE0DFFF08888f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for "Finkel, Hal J." ---2020-05-21 12:15:42 PM---Great, thanks! Are you planning on just talking about th"><font size="2" color="#424282">"Finkel, Hal J." ---2020-05-21 12:15:42 PM---Great, thanks! Are you planning on just talking about these things with slides? Do we have other thi</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">"Finkel, Hal J." <hfinkel@anl.gov></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Tarique Islam <tislam@ca.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Alina Sbirlea <alina.sbirlea@gmail.com>, "Doerfert, Johannes" <jdoerfert@anl.gov>, Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com>, "llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2020-05-21 12:15 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>Great, thanks!<br><br>Are you planning on just talking about these things with slides? Do we have other things to which we can link for people to read?<br><br>-Hal<br><br>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<br><br><hr width="100%" size="2" align="left"><br><b><font face="Calibri">From:</font></b><font face="Calibri"> Tarique Islam <tislam@ca.ibm.com></font><b><font face="Calibri"><br>Sent:</font></b><font face="Calibri"> Thursday, May 21, 2020 8:19:31 AM</font><b><font face="Calibri"><br>To:</font></b><font face="Calibri"> Finkel, Hal J. <hfinkel@anl.gov></font><b><font face="Calibri"><br>Cc:</font></b><font face="Calibri"> Alina Sbirlea <alina.sbirlea@gmail.com>; Doerfert, Johannes <jdoerfert@anl.gov>; Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com>; llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org></font><b><font face="Calibri"><br>Subject:</font></b><font face="Calibri"> RE: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll</font> <br>
<p><font size="2">Hi Hal,</font><br><font size="2"><br>Thanks very much for scheduling the LLVM Alias Analysis Technical Call. I have added more details to the Google document.</font><br><font size="2"><br>Regards,<br>Tarique Islam<br>XL Fortran Compiler Development<br>IBM Toronto Software Lab<br>tislam@ca.ibm.com (905) 413-3190<br></font><br><br><br><img src="cid:1__=8FBB0FE0DFFF08888f9e8a93df938690918c8FB@" width="16" height="16" alt="Inactive hide details for "Finkel, Hal J. via llvm-dev" ---2020-05-18 12:41:56 PM---To join our call on Thursday, May 28th @ 9-"><font size="2" color="#424282">"Finkel, Hal J. via llvm-dev" ---2020-05-18 12:41:56 PM---To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this informati</font><br><font size="2" color="#5F5F5F"><br>From: </font><font size="2">"Finkel, Hal J. via llvm-dev" <llvm-dev@lists.llvm.org></font><font size="2" color="#5F5F5F"><br>To: </font><font size="2">Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com>, Alina Sbirlea <alina.sbirlea@gmail.com></font><font size="2" color="#5F5F5F"><br>Cc: </font><font size="2">"llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org>, "Doerfert, Johannes" <jdoerfert@anl.gov></font><font size="2" color="#5F5F5F"><br>Date: </font><font size="2">2020-05-18 12:41 PM</font><font size="2" color="#5F5F5F"><br>Subject: </font><font size="2">[EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll</font><font size="2" color="#5F5F5F"><br>Sent by: </font><font size="2">"llvm-dev" <llvm-dev-bounces@lists.llvm.org></font><p><hr width="100%" size="2" align="left" noshade><br><br><font face="Calibri"><br>To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this information:</font><br><font face="Calibri"><br>Meeting URL</font><u><font color="#0000FF"><br></font></u><a href="https://bluejeans.com/643493129?src=join_info"><u><font color="#0000FF" face="Calibri">https://bluejeans.com/643493129?src=join_info</font></u></a><br><font face="Calibri"><br>Meeting ID<br>643 493 129</font><br><font face="Calibri"><br>Want to dial in from a phone?</font><br><font face="Calibri"><br>Dial one of the following numbers:<br>+1.312.216.0325 (US (Chicago))<br>+1.408.740.7256 (US (San Jose))<br>+1.866.226.4650 (US Toll Free)<br>(see all numbers - </font><a href="https://www.bluejeans.com/premium-numbers"><u><font color="#0000FF" face="Calibri">https://www.bluejeans.com/premium-numbers</font></u></a><font face="Calibri">)</font><br><font face="Calibri"><br>Enter the meeting ID and passcode followed by #</font><br><font face="Calibri"><br>Connecting from a room system?<br>Dial: bjn.vc or 199.48.152.152 and enter your meeting ID & passcode</font><br><font face="Calibri"><br>On our agenda, we'll have:</font><br><font face="Calibri"><br>1. Scalability challenges and other issues discovered with the current infrastructure (especially, perhaps, with the noalias metadata).<br>2. Proposed solutions: progress, outstanding challenges, how to make progress going forward.</font><br><font face="Calibri"><br>We'll formulate the detailed agenda and take notes from the call using this Google doc: </font><a href="https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing"><u><font color="#0000FF" face="Calibri">https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing</font></u></a><br><br>A summary will then be sent to the mailing list after the call. If you would like to add items to the agenda, please edit the document (or reply to this email).<br><br>Thanks again,<br>Hal<br><font size="2"><br>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory</font><br><br><hr width="100%" size="2" align="left"><b><font face="Calibri"><br>From:</font></b><font face="Calibri"> Finkel, Hal J. <hfinkel@anl.gov></font><b><font face="Calibri"><br>Sent:</font></b><font face="Calibri"> Monday, May 18, 2020 10:24 AM</font><b><font face="Calibri"><br>To:</font></b><font face="Calibri"> Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com>; Alina Sbirlea <alina.sbirlea@gmail.com>; Finkel, Hal J. <hfinkel@anl.gov></font><b><font face="Calibri"><br>Cc:</font></b><font face="Calibri"> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Doerfert, Johannes <jdoerfert@anl.gov></font><b><font face="Calibri"><br>Subject:</font></b><font face="Calibri"> Re: LLVM Alias Analysis Technical Call - Doodle Poll</font> <br><font face="Calibri"><br>Thanks to everyone who participated in the poll. The time that maximizes availability is:</font><br><font face="Calibri"><br>Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC.</font><br><font face="Calibri"><br>I'll send out meeting information shortly.</font><br><font face="Calibri"><br>-Hal</font><br><font size="2"><br>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory</font><br><br><hr width="100%" size="2" align="left"><b><font face="Calibri"><br>From:</font></b><font face="Calibri"> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Finkel, Hal J. via llvm-dev <llvm-dev@lists.llvm.org></font><b><font face="Calibri"><br>Sent:</font></b><font face="Calibri"> Wednesday, May 13, 2020 11:14 AM</font><b><font face="Calibri"><br>To:</font></b><font face="Calibri"> Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com>; Alina Sbirlea <alina.sbirlea@gmail.com></font><b><font face="Calibri"><br>Cc:</font></b><font face="Calibri"> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Doerfert, Johannes <jdoerfert@anl.gov></font><b><font face="Calibri"><br>Subject:</font></b><font face="Calibri"> [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll</font> <br><font face="Calibri"><br>Hi, everyone,</font><br><font face="Calibri"><br>We've had a number of discussions recently, including on the Flang technical call, about potential improvements to LLVM's alias analysis to support handling restrict and restrict-like semantics.</font><br><font face="Calibri"><br>We would like to try having a call to discuss these issues further. Please, if you're interested in joining, indicate your availability (prior to the end of this week):</font><br><u><font color="#0000FF"><br></font></u><a href="https://doodle.com/poll/evhwr2eyfvcf8ib3"><u><font color="#0000FF" face="Calibri">https://doodle.com/poll/evhwr2eyfvcf8ib3</font></u></a><br><font face="Calibri"><br>Thanks again,<br>Hal</font><br><font size="2"><br>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory</font><br><br><hr width="100%" size="2" align="left"><b><font face="Calibri"><br>From:</font></b><font face="Calibri"> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Alina Sbirlea via llvm-dev <llvm-dev@lists.llvm.org></font><b><font face="Calibri"><br>Sent:</font></b><font face="Calibri"> Monday, May 11, 2020 9:49 AM</font><b><font face="Calibri"><br>To:</font></b><font face="Calibri"> Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com></font><b><font face="Calibri"><br>Cc:</font></b><font face="Calibri"> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Doerfert, Johannes <jdoerfert@anl.gov></font><b><font face="Calibri"><br>Subject:</font></b><font face="Calibri"> Re: [llvm-dev] Full restrict support - status update</font> <br><br>Hi Johannes et al,<br><br>Trying to revive this discussion, as the restrict support is relevant for one of our teams.<br><br>Thank you,<br>Alina<br><br>On Tue, Nov 12, 2019 at 1:16 PM Jeroen Dobbelaere via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a>> wrote:
<ul><ul>Hi Johannes et al,<br><br>> -----Original Message-----<br>> From: Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank"><u><font color="#0000FF">jdoerfert@anl.gov</font></u></a>><br>[..]<br>> On 11/06, Jeroen Dobbelaere wrote:<br>> > >From: Alexey Zhikhartsev<br>> > [..]<br>> > > We would love to see your patches merged as soon as possible, so I was<br>> wondering: do you think the lack of bitcode support will prevent that from<br>> happening?<br>> ><br>> > Yes, I think that the lack of bitcode support will prevent it.<br>> ><br>> > During the Developers meeting, I also talked with Hal and Johannes.<br>> > They had some extra remarks:<br>> > - (1) the restrict implementation deserves a separate document. (I am<br>> working on that one)<br>> > - (2) they don't like the naming of 'noalias_sidechannel'.<br>> > - (3) they also have some other mechanisms in mind to add the 'sidechannel'<br>> to the load/store instructions<br>> > (and maybe to function calls, intrinsics; currently that is handled through<br>> llvm.noalias.arg.guard)<br>> ><br>> > For (2) and (3), I am waiting for a proposal from them ;)<br>> <br>> I would like to see the restrict support be merged but, as Jeroen<br>> mentions above, I feel there are two design choices we have to<br>> overthink. Here are short descriptions to get some feedback from the<br>> community:<br>> <br>> (A) Naming and restriction<br>> <br>> The name "sidechannel" is unfortunate, it has various negative<br>> connotations, e.g., the release notes that read:<br>> "LLVM 10.0 now has sidechannel support for your restrict pointer"<br>> will raise a lot of follow up questions.<br>> <br>> What I think we actually do, and what we should call it, is "provenance"<br>> tracking.<br>> <br>> Now beyond the pure renaming of "sidechannel" into "provenance" (or sth.<br>> similar) I want us to decouple provenance tracking from the noalias<br>> logic. Noalias/restrict is one use case in which (pointer) provenance<br>> information is useful but not the only one. If we add some mechanism to<br>> track provenance, let's make it generic and reusable. Note that the<br>> basic ideas are not much different to what the noalias RFC proposed.<br>> The major difference would be that we have provenance information and if<br>> that originates in an `llvm.restrict.decl` call we can use it for<br>> (no)alias queries.<br><br>"provenance" might indeed be a good name.<br><br>There is a big difference between a restrict declaration, and a restrict usage: <br>- the declaration intrinsic (llvm.noalias.decl) is used to track in the cfg the location<br>where the restrict variable was declared. This is important to handle code motion,<br>merging, duplication in a correct way (inlining, loop unrolling, ...)<br>- the restrict usage intrinsics (llvm.noalias and llvm.side.noalias) are used to indicate<br>that from that point on, restrict (noalias) properties are introduced for that pointer.<br>They can exist without an associated 'llvm.noalias.decl' (when the declaration is outside<br>the function.)<br>Given that, I assume that you mean 'llvm.provenance.noalias' (~ llvm.side.noalias) instead<br>of 'llvm.restrict.decl'.<br><br>> <br>> <br>> <br>> (B) Using operand bundles<br>> <br>> Right now, loads and stores are treated differently and given a new<br>> operand. Then there are intrinsics to decode other kinds of information.<br>> As an alternative, we could allow operand bundles on all instructions<br>> and use them to tie information to an instruction. The "sidechannel"<br>> operand of a load would then look something like:<br>> load i32* %p [ "ptr_provenance"(%p_decl) ]<br>> and for a store we could have<br>> store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ]<br>> <br>> The benefit is that we do not change the operand count (which causes a<br>> lot of noise) but we still have to make sure ptr/value uses are not<br>> confused with operand bundle uses. We can attach the information to more<br>> than load/store instructions, also to remove the need for some of the<br>> intrinsics.<br><br>To me, operand bundles sound to be more or less equivalent to the current<br>solution. It might also make the 'instruction cloning' easier, if we can omit the<br>'ptr_provenance' there. The change of the number of operands caused some<br>noise, but it is the changes in the amount of 'uses' of a pointer that refer to the<br>same instruction that caused the most problems. Especially when that instruction<br>was going to be erased. Operand bundles will still need those code changes.<br>(like in parts of D68516 and D68518)<br><br>As the 'Call' instruction already supports operand bundles, it could eliminate the need<br>for the 'llvm.noalias.arg.guard' intrinsic, which combines the normal pointer with the<br>side channel (aka provenance). But, after inlining, we still need to put that information<br>somewhere. Or it should be propagated during inlining.<br>Care must be taken not to lose that information when the 'call' is changed by optimizations<br>as, after inlining, that might result in wrong alias analysis conclusions.<br><br>Are you thinking of "operand bundles" support for just LoadInst/StoreInst, or for all<br>instructions ?<br><br>Greetings,<br><br>Jeroen Dobbelaere<br><br><br>_______________________________________________<br>LLVM Developers mailing list<u><font color="#0000FF"><br></font></u><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a><u><font color="#0000FF"><br></font></u><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><u><font color="#0000FF">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</font></u></a><tt><font size="2">_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org</font></tt><tt><u><font size="2" color="#0000FF"><br></font></u></tt><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"><tt><u><font size="2" color="#0000FF">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</font></u></tt></a><tt><font size="2"> </font></tt><br><br></ul></ul><br><br><BR>
</body></html>