[llvm-dev] FYI: gc relocations on exception path w/RS4GC currently broken

[Philip Reames via llvm-dev]

These are essentially the same options we came up with.

We didn't like the option of changing the dominance rules since it 
seemed like it could lead to illegal transforms.  Consider a code sinker 
which uses dominance to tell when defs are available.  If we had the 
exceptional path dominated by the invokes results, we could have a merge 
point which combined the normal and exceptional edge. Now, data 
dependence would prevent the sink (unless the use was entirely dead), 
but that seems unintuitive at best.

Your second scheme was close to one we came up with, but we hadn't 
thought to use the operand bundles.  This was the least ugly option, but 
why handle the additional complexity if the early spilling works cleanly 
in this case?

Philip

On 01/22/2016 01:38 PM, Reid Kleckner 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?
>
> 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.
>
> That said, I imagine you want to use this exceptional token with more 
> than one invoke, so that you don't end up needing a landingpad per 
> potentially throwing call site. I think this design can be extended to 
> handle that, though.
>
> On Fri, Jan 22, 2016 at 12:35 PM, Philip Reames via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     For anyone following along on ToT using the gc.statepoint
>     mechanism, you should know that ToT is currently not able to
>     express arbitrary exceptional control flow and relocations along
>     exceptional edges. This is a direct result of moving the
>     gc.statepoint representation to using a token type landingpad. 
>     Essentially, we have a design inconsistency where we expect to be
>     able to "resume" a phi of arbitrary landing pads, but we expect
>     relocations to be tied specifically to a particular invoke.
>
>     Chen, Joseph, and I have spent some time talking about how to
>     resolve this.  All of the schemes we've come up with representing
>     relocations using gc.relocates on the exceptional path require
>     either a change to how we define an invoke instruction (something
>     we'd really like to avoid) or a new intrinsic with special
>     treatment in the optimizer so that it basically "becomes part of"
>     the landing pad without actually being the landing pad.  None of
>     us were particular thrilled by the changes involved.
>
>     Given exceptional paths are nearly by definition cold, we're
>     currently exploring another option.  We're considering having
>     RS4GC insert explicit spill slots at the IR level (via allocas)
>     for values live along exceptional paths, and leaving all of the
>     normal path values represented as gc.relocates.  This avoids the
>     need for another IR extension, makes it slightly easier to meet an
>     ABI requirement Joseph has, and provides a better platform for
>     lowering experimentation.  Joseph is working on implementing this
>     and will probably have something up for review next week or the
>     week after. Once that's in, we're going to run some performance
>     experiments to see if it's a viable lowering strategy even without
>     Joseph's particular ABI requirement, and if so, make that the
>     standard way of representing relocations on exceptional edges.
>
>     Assuming this approach works, we're going to defer solving the
>     problem of how to cleanly represent explicit relocations along the
>     exceptional path until a later point in time.  In particular, the
>     value of the explicit relocations comes mainly from being able to
>     lower them efficiently to register uses.  Since the work to
>     integrate relocations with the register allocator hasn't happened
>     and doesn't look like it's going to happen in the near term (*),
>     this seems like a reasonable compromise.
>
>     Philip
>
>     (*) To give some context on this, it turns out one of our initial
>     starting assumptions was wrong in practice.  We expected the
>     quality of lowering for the gc arguments at statepoint/safepoint
>     to be very important for overall code quality.  While this may
>     some day become true, we've found that whenever we encounter a hot
>     safepoint, the problem is usually that we didn't inline
>     appropriately.  As a result, we've ended up fixing (out of tree)
>     inlining or devirtualization bugs rather than working on the
>     lowering itself. For us, a truly hot megamorphic call site has
>     turned out to be a very rare beast.  Worth noting is that this is
>     only true because we're a high tier JIT with good profiling
>     information.  It's likely that other users who don't have the same
>     design point may find the lowering far more problematic; in fact,
>     we have some evidence this may already be true.
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto: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/20160124/1b1f41d1/attachment.html>