<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 07/22/2015 11:29 PM, David Majnemer
wrote:<br>
</div>
<blockquote
cite="mid:CAL7bZ_ftZjvEh72aZuYLXNJcBExaxj38C3U8UzV3ygb9QB8jSg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jul 22, 2015 at 1:40 PM,
Philip Reames <span dir="ltr"><<a moz-do-not-send="true" href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<br>
On 07/21/2015 05:45 PM, Reid Kleckner wrote:<br>
</span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
rnk added a comment.<br>
<br>
In <a moz-do-not-send="true" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11097-23209400&d=AwMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=hd-svm4Lmf9mHMHV-xfLnqsLtieqVIp6Mr5w1x5bt80&s=A2dLtWwzyRSciluH6DO7SQMQywOQWlTq-maKxXPEGXw&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11097#209400</a>,
@reames wrote:<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In
<a moz-do-not-send="true" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11097-23209367&d=AwMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=hd-svm4Lmf9mHMHV-xfLnqsLtieqVIp6Mr5w1x5bt80&s=jeyoY-dRZLA0uDKGP7e9NfCQC6MPniYQahMcKXZSIKM&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11097#209367</a>,
@majnemer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">@reames
thinking about it a little more, would you be
happier with `CatchPadInst` instead of
`CatchBlockInst`, etc. and `isEHPad` instead of
`isEHBlock`?<br>
</blockquote>
</blockquote>
<br>
I like the pad terminology. The block terminology came
about because we're really imbuing some special
properties on the whole BasicBlock. Currently the
landingpad instruction is the only instruction with
the power to make an edge unsplittable, for example.
Anyway, `pad` sounds good to me.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">That
would help. Reusing block causes confusion with the
widespread use of "block" to refer to a basic block
in the code base.<br>
More generally, consistency in the terminology would
be a good thing. Let me lay out my current
understanding:<br>
- A X-"pad" is a place the exceptional control flow
might resume.<br>
- A catch is a specific type of "pad" which models a
language/ABI level catch clause. A catch is
exception type specific.<br>
- A cleanup is a specific type of "pad" which models
scope exit without an explicit exception type.<br>
- Both catch and cleanup are statically scoped.
There's a begin and end construct for each.<br>
In this context, what is a terminateblock? It's
clearly a "pad", but why is not just a cleanup?<br>
</blockquote>
<br>
Currently, Clang expresses noexcept() as a catch-all
clause that simply calls terminate. This is
inefficient for both Itanium and MSVC because both
LSDA tables can express noexcept with a single bit. We
do it because it makes it possible to inline one
noexcept function into another EH scope without
teaching the inliner that it should transform some
function attribute into LLVM IR that makes some C++
runtime function call.<br>
<br>
Terminatepad solves this all by keeping data as data,
allowing late IR preparation passes to expand the IR
into code (catch-all or filter) or leave it alone if
it can be encoded in the table.<br>
</span></blockquote>
Just to be clear, there's no ABI requirement that a
terminate block NOT be a cleanup with a terminate call
right? If so, why can't this be expressed via a late
pattern match on the MI level? If it's "just an
optimization", I'm really hesitant to complicate the IR
for this corner case.</blockquote>
<div><br>
</div>
<div>We need the ability to only cause termination if the
personality feels like the terminatepad is worthy of it.
For example, it is possible to have a "throw(int)"
exception specification which implies that all exceptions
thrown, other than those of type int, should result in
program termination. Implementing this requires knowledge
of the current exception's type which we don't have access
to as code. However, we can encode this as data in the
LSDA table. Given these constraints, I don't see think
this could be encoded as a cleanup.<br>
</div>
</div>
</div>
</div>
</blockquote>
To make sure I understood the problem correctly, you basically said
there's not a way to describe a catch which catches all but a given
type of exception right? <br>
<br>
Am I correct in believing that you could encode this as a catch for
the excluded type which rethrows and a catch-all which calls
terminate? Not saying you should; just trying to understand the
problem. <br>
<blockquote
cite="mid:CAL7bZ_ftZjvEh72aZuYLXNJcBExaxj38C3U8UzV3ygb9QB8jSg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On
the topic of motivation, I still feel like I'm
missing a lot. In particular, it feels like the
catchpad, cleanuppad, and terminatepad are really
close to what's already described by landingpad(*).
I get that you need to prevent merging of catch
blocks, but why isn't a single "pad fence" at the
end of each clause which is unmergeable solve that
problem?<br>
- We might end up changing how you describe a catch
clause, but the idea is already there. You do seem
to need different arguments then the existing catch
clause bits.<br>
</blockquote>
<br>
Yeah, they are the same set of clauses. :) However,
with the new instructions, we won't need to do
impossibly error-prone pattern matching.<br>
</blockquote>
</span>
I really don't get this statement. How is a landingpad
with a catch clause instruction fundamentally different
then a catchpad? Is it the fact that landingpads
w/compatible clauses be merged? Or is there something
more here?</blockquote>
<div><br>
</div>
<div>The landingpad model requires comparing against the
selector to determine what should happen next. We don't
have that luxury with our personality routine.</div>
</div>
</div>
</div>
</blockquote>
<br>
<blockquote
cite="mid:CAL7bZ_ftZjvEh72aZuYLXNJcBExaxj38C3U8UzV3ygb9QB8jSg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
How would a "pad fence" statically indicate that after
running this cleanup, the next EH action is that catch
block over there? Right now we try to figure this out
by walking the CFG and trying to find the next
conditional branch based on a comparison of the EH
selector value. I think the primary failure mode of
WinEHPrepare today is that we inline a destructor
containing control flow, and then this analysis falls
over. I'd rather not have to do dataflow analysis to
rediscover this very basic nesting property of the C++
source code.<br>
</blockquote>
</span>
I was picturturing something like this:<br>
padfence<br>
br label %next<br>
<br>
The control flow would be separate. We don't currently
allow branches to landingpads, but that seems like a
smaller change than adding a bunch of new instructions.<br>
<br>
We'd also need to prevent splitting the padfence from the
end of it's block, but that seems workable. Doing this
gives us one new instruction rather than (catchpadend,
catchret, cleanupret).</blockquote>
<div><br>
</div>
<div>Does a padfence prevent other instructions from flowing
between itself and the branch? If it does not, where
would such instructions go? They cannot be encoded in the
LSDA.</div>
</div>
</div>
</div>
</blockquote>
"We'd also need to *prevent splitting the padfence from the end of
it's block*, but that seems workable." We already do this for PHIs
at the other end of the block, so restricting a padfence to be
immediately before the terminator seems entirely feasible. <br>
<blockquote
cite="mid:CAL7bZ_ftZjvEh72aZuYLXNJcBExaxj38C3U8UzV3ygb9QB8jSg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Essentially, the new instructions are exactly that: a
really strong "pad fence" that keeps all the data and
control flow transfers that we want to know about
grouped together.<br>
</blockquote>
</span>
I get that. I'm mostly just concerned that we need this
many new instructions for one new concept in the IR.<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
<a moz-do-not-send="true" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11097&d=AwMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=hd-svm4Lmf9mHMHV-xfLnqsLtieqVIp6Mr5w1x5bt80&s=j8_A9xHbvxF-4UOnJVd-DrcP9ibHONiYilHYfnCcjas&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11097</a><br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>