[llvm-dev] Operand bundles and gc transition arguments

[Sanjoy Das via llvm-dev]

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