<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks to everyone who participated in the poll. The time that maximizes availability is:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I'll send out meeting information shortly.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-Hal</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory</div>
</span></font></div>
</div>
</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Finkel, Hal J. via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> Wednesday, May 13, 2020 11:14 AM<br>
<b>To:</b> Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com>; Alina Sbirlea <alina.sbirlea@gmail.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Doerfert, Johannes <jdoerfert@anl.gov><br>
<b>Subject:</b> [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll</font>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hi, everyone,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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):</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<a href="https://doodle.com/poll/evhwr2eyfvcf8ib3" id="LPlnk510266">https://doodle.com/poll/evhwr2eyfvcf8ib3</a></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks again,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hal</div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div id="x_Signature">
<div class="x_BodyFragment"><font size="2"><span style="font-size:10pt">
<div class="x_PlainText">Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory</div>
</span></font></div>
</div>
</div>
<div>
<div id="x_appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Alina Sbirlea via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> Monday, May 11, 2020 9:49 AM<br>
<b>To:</b> Jeroen Dobbelaere <Jeroen.Dobbelaere@synopsys.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Doerfert, Johannes <jdoerfert@anl.gov><br>
<b>Subject:</b> Re: [llvm-dev] Full restrict support - status update</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi Johannes et al,<br>
<div><br>
</div>
<div>Trying to revive this discussion, as the restrict support is relevant for one of our teams.</div>
<div><br>
</div>
<div>Thank you,</div>
<div>Alina</div>
</div>
<br>
<div class="x_x_gmail_quote">
<div dir="ltr" class="x_x_gmail_attr">On Tue, Nov 12, 2019 at 1:16 PM Jeroen Dobbelaere via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="x_x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
Hi Johannes et al,<br>
<br>
> -----Original Message-----<br>
> From: Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</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<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>