[llvm-dev] Full restrict support - status update

[Alina Sbirlea via llvm-dev]

Hi Johannes et al,

Trying to revive this discussion, as the restrict support is relevant for
one of our teams.

Thank you,
Alina

On Tue, Nov 12, 2019 at 1:16 PM Jeroen Dobbelaere via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Johannes et al,
>
> > -----Original Message-----
> > From: Doerfert, Johannes <jdoerfert at anl.gov>
> [..]
> > On 11/06, Jeroen Dobbelaere wrote:
> > > >From: Alexey Zhikhartsev
> > > [..]
> > > > We would love to see your patches merged as soon as possible, so I
> was
> > wondering: do you think the lack of bitcode support will prevent that
> from
> > happening?
> > >
> > > Yes, I think that the lack of bitcode support will prevent it.
> > >
> > > During the Developers meeting, I also talked with Hal and Johannes.
> > > They had some extra remarks:
> > > - (1) the restrict implementation deserves a separate document. (I am
> > working on that one)
> > > - (2) they don't like the naming of 'noalias_sidechannel'.
> > > - (3) they also have some other mechanisms in mind to add the
> 'sidechannel'
> > to the load/store instructions
> > >        (and maybe to function calls, intrinsics; currently that is
> handled through
> > llvm.noalias.arg.guard)
> > >
> > > For (2) and (3), I am waiting for a proposal from them ;)
> >
> > I would like to see the restrict support be merged but, as Jeroen
> > mentions above, I feel there are two design choices we have to
> > overthink. Here are short descriptions to get some feedback from the
> > community:
> >
> > (A) Naming and restriction
> >
> > The name "sidechannel" is unfortunate, it has various negative
> > connotations, e.g., the release notes that read:
> >  "LLVM 10.0 now has sidechannel support for your restrict pointer"
> > will raise a lot of follow up questions.
> >
> > What I think we actually do, and what we should call it, is "provenance"
> > tracking.
> >
> > Now beyond the pure renaming of "sidechannel" into "provenance" (or sth.
> > similar) I want us to decouple provenance tracking from the noalias
> > logic. Noalias/restrict is one use case in which (pointer) provenance
> > information is useful but not the only one. If we add some mechanism to
> > track provenance, let's make it generic and reusable. Note that the
> > basic ideas are not much different to what the noalias RFC proposed.
> > The major difference would be that we have provenance information and if
> > that originates in an `llvm.restrict.decl` call we can use it for
> > (no)alias queries.
>
> "provenance" might indeed be a good name.
>
> There is a big difference between a restrict declaration, and a restrict
> usage:
> - the declaration intrinsic (llvm.noalias.decl) is used to track in the
> cfg the location
>    where the restrict variable was declared. This is important to handle
> code motion,
>    merging, duplication in a correct way (inlining, loop unrolling, ...)
> - the restrict usage intrinsics (llvm.noalias and llvm.side.noalias) are
> used to indicate
>    that from that point on, restrict (noalias) properties are introduced
> for that pointer.
>   They can exist without an associated 'llvm.noalias.decl' (when the
> declaration is outside
>    the function.)
> Given that, I assume that you mean 'llvm.provenance.noalias' (~
> llvm.side.noalias) instead
> of 'llvm.restrict.decl'.
>
> >
> >
> >
> > (B) Using operand bundles
> >
> > Right now, loads and stores are treated differently and given a new
> > operand. Then there are intrinsics to decode other kinds of information.
> > As an alternative, we could allow operand bundles on all instructions
> > and use them to tie information to an instruction. The "sidechannel"
> > operand of a load would then look something like:
> >   load i32* %p [ "ptr_provenance"(%p_decl) ]
> > and for a store we could have
> >   store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ]
> >
> > The benefit is that we do not change the operand count (which causes a
> > lot of noise) but we still have to make sure ptr/value uses are not
> > confused with operand bundle uses. We can attach the information to more
> > than load/store instructions, also to remove the need for some of the
> > intrinsics.
>
> To me, operand bundles sound to be more or less equivalent to the current
> solution. It  might also make the 'instruction cloning' easier, if we can
> omit the
> 'ptr_provenance' there. The change of the number of operands caused some
> noise, but it is the changes in the amount of 'uses' of a pointer that
> refer to the
> same instruction that caused the most problems. Especially when that
> instruction
> was going to be erased. Operand bundles will still need those code changes.
> (like in parts of D68516 and D68518)
>
> As the 'Call' instruction already supports operand bundles, it could
> eliminate the need
> for the 'llvm.noalias.arg.guard' intrinsic, which combines the normal
> pointer with the
> side channel (aka provenance). But, after inlining, we still need to put
> that information
> somewhere. Or it should be propagated during inlining.
> Care must be taken not to lose that information when the 'call' is changed
> by optimizations
> as, after inlining, that might result in wrong alias analysis conclusions.
>
> Are you thinking of "operand bundles" support for just LoadInst/StoreInst,
> or for all
> instructions ?
>
> Greetings,
>
> Jeroen Dobbelaere
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200511/1cf206e6/attachment.html>