[llvm-dev] FYI: gc relocations on exception path w/RS4GC currently broken
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 22 14:03:22 PST 2016
On Fri, Jan 22, 2016 at 1:38 PM, Reid Kleckner <rnk at google.com> wrote:
> So, here's a crazy idea. What if we change the definition of dominance for
> invokes that produce tokens so that the token return value is live out the
> exceptional edge?
We'd then need some way to prevent a gc.result(%token) from appearing
on the landingpad basic block. Not that it can't be done, but we'd
have to say something like "even though the token dominates both
branches, only one of them can have gc.result uses of the token type".
Now if LLVM allowed instructions to have multiple defs, we could have
gc.statepoint produce two tokens, and have one of them dominate the
exception path (the one that you couldn't have gc.result hang off of)
and the other one dominate the normal path; but that'd be a very
disruptive change I think.
> If that's too crazy, what if we used operand bundles to make a new token
> that "forward declares" the statepoint token:
> %exceptional_token = call token @llvm.gc.exceptional.token()
> %normal_token = invoke @llvm.gc.experimental.statepoint(....) [ "eh_token"
> token %exceptional_token ]
> to label %normal_dest unwind label %lpad_dest
> ...
> lpad_dest:
> %ehvals = { i8*, i32 } landingpad ... like usual
> %p1 = @llvm.gc.relocate(token %exceptional_token)
>
> A given exceptional token can be used with exactly one or zero GC statepoint
> calls, so a late pass can map from one to the other and insert reloads in
> the usual way.
Then we'll be stuck with gc.relocate being at least readonly, since we
don't want to allow the above to transform into this:
%exceptional_token = call token @llvm.gc.exceptional.token()
%p1 = @llvm.gc.relocate(token %exceptional_token)
%normal_token = invoke @llvm.gc.experimental.statepoint(....) [ "eh_token"
token %exceptional_token ]
to label %normal_dest unwind label %lpad_dest
...
lpad_dest:
%ehvals = { i8*, i32 } landingpad ... like usual
-- Sanjoy
More information about the llvm-dev
mailing list