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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 2 10:51:40 PDT 2015


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>


More information about the llvm-dev mailing list