<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="gmail_quote"><div dir="ltr" class="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="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>