[llvm-dev] RFC: Add "operand bundles" to calls and invokes

Swaroop Sridhar via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 20 13:16:41 PDT 2015

Looks good to me too. Thanks.


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

More information about the llvm-dev mailing list