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

[Sanjoy Das via llvm-dev]

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