llvm dev - Aug 2015 - RFC: Add "operand bundles" to calls and invokes

A high level summary of the proposal as it stands right now (from my
perspective), after
incorporating Philip's suggestions:

 1. Operand bundles are a way to associate a set of SSA values with a
    call or invoke.

 2. Operand bundles are lowered in some arbitrary bundle-tag specific
    manner.

 3. The optimizer can optimize around operand bundles with (roughly)
    the assumption that they're just extra arguments to the call /
    invoke.  In particular, the optimizer does not have to assume that
    operand bundles imply any extra memory / IO effects than what is
    apparent from the call.

 4. Through the discussion we came up with a re-ordering
    restriction we'll have to place on function calls / invokes that
    may deoptimize their caller.  This is orthogonal to the operand
    bundles discussion, and will be implemented as a separate call
    attribute.

Is everyone on the thread comfortable enough with the general idea
that I can start writing patches and sending them in for review?

-- Sanjoy

On 08/19/2015 06:09 PM, Sanjoy Das wrote:
> A high level summary of the proposal as it stands right now (from my
> perspective), after
> incorporating Philip's suggestions:
>
>   1. Operand bundles are a way to associate a set of SSA values with a
>      call or invoke.
>
>   2. Operand bundles are lowered in some arbitrary bundle-tag specific
>      manner.
>
>   3. The optimizer can optimize around operand bundles with (roughly)
>      the assumption that they're just extra arguments to the call /
>      invoke.  In particular, the optimizer does not have to assume that
>      operand bundles imply any extra memory / IO effects than what is
>      apparent from the call.
>
>   4. Through the discussion we came up with a re-ordering
>      restriction we'll have to place on function calls / invokes that
>      may deoptimize their caller.  This is orthogonal to the operand
>      bundles discussion, and will be implemented as a separate call
>      attribute.
>
> Is everyone on the thread comfortable enough with the general idea
> that I can start writing patches and sending them in for review?
I am.
>
> -- Sanjoy

Looks good to me too. Thanks.

Swaroop.

-----Original Message-----
From: Philip Reames [mailto:listmail at philipreames.com] 
Sent: Wednesday, August 19, 2015 6:55 PM
To: Sanjoy Das <sanjoy at playingwithpointers.com>
Cc: Hal Finkel <hfinkel at anl.gov>; David Majnemer <david.majnemer at
gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; Chandler Carruth
<chandlerc at gmail.com>; Nick Lewycky <nlewycky at google.com>;
Chen Li <meloli87 at gmail.com>; Russell Hadley <rhadley at
microsoft.com>; Kevin Modzelewski <kmod at dropbox.com>; Swaroop
Sridhar <Swaroop.Sridhar at microsoft.com>; rudi at dropbox.com; Pat
Gavlin <pagavlin at microsoft.com>; Joseph Tremoulet <jotrem at
microsoft.com>; Reid Kleckner <rnk at google.com>
Subject: Re: RFC: Add "operand bundles" to calls and invokes



On 08/19/2015 06:09 PM, Sanjoy Das wrote:
> A high level summary of the proposal as it stands right now (from my
> perspective), after
> incorporating Philip's suggestions:
>
>   1. Operand bundles are a way to associate a set of SSA values with a
>      call or invoke.
>
>   2. Operand bundles are lowered in some arbitrary bundle-tag specific
>      manner.
>
>   3. The optimizer can optimize around operand bundles with (roughly)
>      the assumption that they're just extra arguments to the call /
>      invoke.  In particular, the optimizer does not have to assume that
>      operand bundles imply any extra memory / IO effects than what is
>      apparent from the call.
>
>   4. Through the discussion we came up with a re-ordering
>      restriction we'll have to place on function calls / invokes that
>      may deoptimize their caller.  This is orthogonal to the operand
>      bundles discussion, and will be implemented as a separate call
>      attribute.
>
> Is everyone on the thread comfortable enough with the general idea
> that I can start writing patches and sending them in for review?
I am.
>
> -- Sanjoy