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

[Philip Reames via llvm-dev]

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.