llvm dev - Mar 2020 - Operand Bundles generalization RE: Full restrict support - status update

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
>

Hi Jeroen,

On Fri, Mar 6, 2020 at 4:45 AM Jeroen Dobbelaere
<Jeroen.Dobbelaere at synopsys.com> wrote:
> 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
It has been a while since I worked on this, but

1. I expect the data-structure bits of general operand bundles to be
fairly straightforward.  That is, it is probably only a few days work
to start attaching operand bundles to instructions like load,
getelementptr etc. and making sure that LLVM passes do not crash.

2. I expect the high level semantic modelling to be significantly more
challenging.  For instance, what does it mean for a getelementptr to
have an operand bundle?  Does it invalidate some existing
optimizations?  How will we ensure that we've discovered all of the
transforms and analyses that needed to be changed?

-- Sanjoy
>
> 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
> >
>