<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
These are essentially the same options we came up with. <br>
<br>
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. <br>
<br>
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?<br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 01/22/2016 01:38 PM, Reid Kleckner
wrote:<br>
</div>
<blockquote
cite="mid:CACs=ty+VVv69G+8v=7Gh6m-wMnPYBDkKGJ02X0h0Gtzb0S4gQg@mail.gmail.com"
type="cite">
<div dir="ltr">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?
<div><br>
</div>
<div>If that's too crazy, what if we used operand bundles to
make a new token that "forward declares" the statepoint token:</div>
<div> %exceptional_token = call token
@llvm.gc.exceptional.token()</div>
<div> %normal_token = invoke
@llvm.gc.experimental.statepoint(....) [ "eh_token" token
%exceptional_token ]</div>
<div> to label %normal_dest unwind label %lpad_dest</div>
<div>...</div>
<div>lpad_dest:</div>
<div> %ehvals = { i8*, i32 } landingpad ... like usual</div>
<div> %p1 = @llvm.gc.relocate(token %exceptional_token)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jan 22, 2016 at 12:35 PM,
Philip Reames via llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Philip<br>
<br>
(*) 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.<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>