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

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

Initial set of patches are up for review at:

http://reviews.llvm.org/D12455
http://reviews.llvm.org/D12456
http://reviews.llvm.org/D12457

Thanks,
-- Sanjoy

Just wanted to confirm that I too like where this is going. =] I think
Philip and others have really handled the bulk of the review, and I'm very
comfortable with them finishing the patch review.

One issue where I wanted to chime in, hopefully just to add some clarity,
is the "readonly" vs operand bundle set of (interrelated) issues.

First, as I think Philip already said, I think it is important that a
readonly or a readnone attribute on a call is absolute. Optimizations
shouldn't have to go look for an operand bundle. Instead, we should prevent
the call-side attributes from being added.

I think there may be a separate way of specifying all of this that makes
things clearer. Operand bundles imply that when lowering, the call may be
wrapped with a call to an external function before and/or after the called
function, with the bundled operands escaped into those external functions
which may capture, etc.

This both gives you the escape semantics, and it gives you something else;
the runtime function might not return! That should (I think) exactly
capture the semantic issue you were worried about with deopt. Because
control may never reach the called function, or may never return to the
caller even if the callee returns, code motion of side-effects would be
clearly prohibited.

Does this make sense as an approach to specifying things? (Or worse, are
you already there, and I'm just arriving late to the party?)

-Chandler

On Fri, Aug 28, 2015 at 4:42 PM Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Initial set of patches are up for review at:
>
> http://reviews.llvm.org/D12455
> http://reviews.llvm.org/D12456
> http://reviews.llvm.org/D12457
>
> Thanks,
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150902/d07af204/attachment.html>