[llvm-dev] Operand Bundles generalization RE: Full restrict support - status update

[Jeroen Dobbelaere via llvm-dev]

In an attempt to restart the discussion:
(Added Sanjoy, as he has done a lot of work on the operand bundles)

In order to move things forward, I would like to find out:
 -  how hard an implementation of generalized operand bundles would be, and
  - how we can minimize the impact on parts of the compiler that don't
    need operand bundles

So that we can compare it to my current solution for the provenance (former
'noalias side_channel') of a pointer operand of a load/store instruction. 

Either by support operand bundles on any instruction (1), or, if that would
have too big of an impact, by extending its support to load/store instructions (2).

Sanjay, as you have done a decent amount of work on Operand Bundles, maybe you
can give some insight on the feasibility, possible performance/memory impact,
amount of work ?

Thanks,

Jeroen Dobbelaere


> -----Original Message-----
> From: Jeroen Dobbelaere
> Sent: Tuesday, November 12, 2019 22:15
> To: Doerfert, Johannes <jdoerfert at anl.gov>
> Cc: Alexey Zhikhartsev <alexey.zhikhar at gmail.com>; Finkel, Hal J.
> <hfinkel at anl.gov>; llvm-dev at lists.llvm.org
> Subject: RE: [llvm-dev] Full restrict support - status update
> 
> Hi Johannes et al,
> 
> > -----Original Message-----
> > From: Doerfert, Johannes <jdoerfert at anl.gov>
> [..]
[..]
> > (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
>