llvm dev - Oct 2015 - Operand bundles and gc transition arguments

As part of adding `"deopt"` operand bundles, we're aiming to
change
RewriteStatepointsForGC (called RS4GC henceforth) from rewriting
existing `gc.statepoint` calls to transforming normal LLVM calls and
invokes into `gc.statepoint` calls and invokes (i.e. to do
PlaceSafepoints + RS4GC in one step).  This will make `gc.statepoint`
an artifact of the gc lowering strategy that only appears very late in
the pipeline, and not a generic "meta call".  For us, this opens up
the possibility of making the optimizer work well around calls with
deopt state (e.g. be able to inline through calls with deopt state).

Currently a "non-rewritten" `gc.statepoint` call (i.e. before RS4GC
has run, without explicit relocations) carries two categories of
information:

   1. Deoptimization state.
   2. GC Transition args and StatepointFlags.

Once we have relatively stable[1] support for operand bundles
upstream, LLVM will be able to carry deoptimization state directly on
calls and invokes using a `"deopt"` operand bundle.  This will obviate
reason (1) for keeping non-rewritten `gc.statepoint` s in the IR.
This leaves (2), which I think can be dealt with in three ways:

  a. Change LLILC to emit unmanaged calls with a `"gc-transition"`
     operand bundle holding the transition arguments instead of a
     `gc.statepoint` wrapped call holding them.  RS4GC would then would
     then parse and transcribe that information into the "transition
     args" field of the `gc.statepoint` it creates.

  b. Have an adapter pass that "unwraps" `gc.statepoint` calls into
     normal calls that have whatever transition args the
     `gc.statepoint` had in its `"gc-transition"` operand bundle
     (i.e. "call @gc.statepoint(@f, transition_args={foo, bar})" =>
     "call @f() [ "gc-transition"(foo, bar) ]").  Run this
adapter pass
     before RS4GC and keep LLILC unchanged.

  c. Have RS4GC operate in two modes -- a "legacy" mode that works
like
     today's RS4GC, and a mode that is operand bundle aware.

Overall, I think (a) will be both faster and more elegant than
(b).  (c) is basically what D13372 does, and I'd strongly prefer not
keeping it in tree long term.

What do you think?  This does not need to be decided / designed
immediately -- we're still several weeks (at least) away from a
stable, working implementation of operand bundles.  But I figured that
it makes sense to start the discussion sooner than later.


[1]: i.e. the optimizer does not miscompile IR with operand bundles

-- Sanjoy

>  a. Change LLILC to emit unmanaged calls with a `"gc-transition"`
>     operand bundle holding the transition arguments instead of a
>     `gc.statepoint` wrapped call holding them.  RS4GC would then would
>     then parse and transcribe that information into the "transition
>     args" field of the `gc.statepoint` it creates.
+1 for (a). This sounds like exactly what I had in mind when we first discussed
operand bundles.

We'd be happy to do the work for this if you'd like (once deopt bundles
have landed).

- Pat
________________________________________
From: Sanjoy Das <sanjoy at playingwithpointers.com>
Sent: Wednesday, October 14, 2015 8:44:03 PM
To: Swaroop Sridhar; Pat Gavlin; Philip Reames; llvm-dev
Subject: Operand bundles and gc transition arguments

As part of adding `"deopt"` operand bundles, we're aiming to
change
RewriteStatepointsForGC (called RS4GC henceforth) from rewriting
existing `gc.statepoint` calls to transforming normal LLVM calls and
invokes into `gc.statepoint` calls and invokes (i.e. to do
PlaceSafepoints + RS4GC in one step).  This will make `gc.statepoint`
an artifact of the gc lowering strategy that only appears very late in
the pipeline, and not a generic "meta call".  For us, this opens up
the possibility of making the optimizer work well around calls with
deopt state (e.g. be able to inline through calls with deopt state).

Currently a "non-rewritten" `gc.statepoint` call (i.e. before RS4GC
has run, without explicit relocations) carries two categories of
information:

   1. Deoptimization state.
   2. GC Transition args and StatepointFlags.

Once we have relatively stable[1] support for operand bundles
upstream, LLVM will be able to carry deoptimization state directly on
calls and invokes using a `"deopt"` operand bundle.  This will obviate
reason (1) for keeping non-rewritten `gc.statepoint` s in the IR.
This leaves (2), which I think can be dealt with in three ways:

  a. Change LLILC to emit unmanaged calls with a `"gc-transition"`
     operand bundle holding the transition arguments instead of a
     `gc.statepoint` wrapped call holding them.  RS4GC would then would
     then parse and transcribe that information into the "transition
     args" field of the `gc.statepoint` it creates.

  b. Have an adapter pass that "unwraps" `gc.statepoint` calls into
     normal calls that have whatever transition args the
     `gc.statepoint` had in its `"gc-transition"` operand bundle
     (i.e. "call @gc.statepoint(@f, transition_args={foo, bar})" =>
     "call @f() [ "gc-transition"(foo, bar) ]").  Run this
adapter pass
     before RS4GC and keep LLILC unchanged.

  c. Have RS4GC operate in two modes -- a "legacy" mode that works
like
     today's RS4GC, and a mode that is operand bundle aware.

Overall, I think (a) will be both faster and more elegant than
(b).  (c) is basically what D13372 does, and I'd strongly prefer not
keeping it in tree long term.

What do you think?  This does not need to be decided / designed
immediately -- we're still several weeks (at least) away from a
stable, working implementation of operand bundles.  But I figured that
it makes sense to start the discussion sooner than later.


[1]: i.e. the optimizer does not miscompile IR with operand bundles

-- Sanjoy

Pat Gavlin wrote:
>>   a. Change LLILC to emit unmanaged calls with a
`"gc-transition"`
>>      operand bundle holding the transition arguments instead of a
>>      `gc.statepoint` wrapped call holding them.  RS4GC would then would
>>      then parse and transcribe that information into the
"transition
>>      args" field of the `gc.statepoint` it creates.
>
> +1 for (a). This sounds like exactly what I had in mind when we first
discussed operand bundles.
>
> We'd be happy to do the work for this if you'd like (once deopt
bundles have landed).
Great, you can't back out of this now! :P

On a more serious note, deopt bundles have "landed", but they're
not stable yet.  I'll reply here once I think it is
reasonably stable, which should be ~2-4 weeks from now.

-- Sanjoy
>
> - Pat
> ________________________________________
> From: Sanjoy Das<sanjoy at playingwithpointers.com>
> Sent: Wednesday, October 14, 2015 8:44:03 PM
> To: Swaroop Sridhar; Pat Gavlin; Philip Reames; llvm-dev
> Subject: Operand bundles and gc transition arguments
>
> As part of adding `"deopt"` operand bundles, we're aiming to
change
> RewriteStatepointsForGC (called RS4GC henceforth) from rewriting
> existing `gc.statepoint` calls to transforming normal LLVM calls and
> invokes into `gc.statepoint` calls and invokes (i.e. to do
> PlaceSafepoints + RS4GC in one step).  This will make `gc.statepoint`
> an artifact of the gc lowering strategy that only appears very late in
> the pipeline, and not a generic "meta call".  For us, this opens
up
> the possibility of making the optimizer work well around calls with
> deopt state (e.g. be able to inline through calls with deopt state).
>
> Currently a "non-rewritten" `gc.statepoint` call (i.e. before
RS4GC
> has run, without explicit relocations) carries two categories of
> information:
>
>     1. Deoptimization state.
>     2. GC Transition args and StatepointFlags.
>
> Once we have relatively stable[1] support for operand bundles
> upstream, LLVM will be able to carry deoptimization state directly on
> calls and invokes using a `"deopt"` operand bundle.  This will
obviate
> reason (1) for keeping non-rewritten `gc.statepoint` s in the IR.
> This leaves (2), which I think can be dealt with in three ways:
>
>    a. Change LLILC to emit unmanaged calls with a
`"gc-transition"`
>       operand bundle holding the transition arguments instead of a
>       `gc.statepoint` wrapped call holding them.  RS4GC would then would
>       then parse and transcribe that information into the "transition
>       args" field of the `gc.statepoint` it creates.
>
>    b. Have an adapter pass that "unwraps" `gc.statepoint` calls
into
>       normal calls that have whatever transition args the
>       `gc.statepoint` had in its `"gc-transition"` operand bundle
>       (i.e. "call @gc.statepoint(@f, transition_args={foo, bar})"
=>
>       "call @f() [ "gc-transition"(foo, bar) ]").  Run
this adapter pass
>       before RS4GC and keep LLILC unchanged.
>
>    c. Have RS4GC operate in two modes -- a "legacy" mode that
works like
>       today's RS4GC, and a mode that is operand bundle aware.
>
> Overall, I think (a) will be both faster and more elegant than
> (b).  (c) is basically what D13372 does, and I'd strongly prefer not
> keeping it in tree long term.
>
> What do you think?  This does not need to be decided / designed
> immediately -- we're still several weeks (at least) away from a
> stable, working implementation of operand bundles.  But I figured that
> it makes sense to start the discussion sooner than later.
>
>
> [1]: i.e. the optimizer does not miscompile IR with operand bundles
>
> -- Sanjoy