Sanjoy Das via llvm-dev
2015-Oct-15 03:44 UTC
[llvm-dev] 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 via llvm-dev
2015-Oct-16 16:51 UTC
[llvm-dev] Operand bundles and gc transition arguments
> 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
Sanjoy Das via llvm-dev
2015-Oct-18 22:28 UTC
[llvm-dev] Operand bundles and gc transition arguments
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