[llvm-dev] Full restrict support - status update

[Doerfert, Johannes via llvm-dev]

Apologies for the delay.

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.



(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.


Please let me know what you think!

Cheers,
  Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191112/178e25fd/attachment-0001.sig>