<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I have no further comments. All of my points from previous
discussion stand, but it sounds like you have addressed those.<br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 11/04/2015 01:23 PM, Akira Hatanaka
wrote:<br>
</div>
<blockquote
cite="mid:CAB297QxvBybcEwnaSXL2B7txPd3FRRfopT4wKB8Om=Bjzy6YWA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>I've been discussing the clang-side patch and making
changes based on the feedback I got for the last few weeks.
Aaron has reviewed the patch and he thinks it's OK now.</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://reviews.llvm.org/D12922">http://reviews.llvm.org/D12922</a><br>
</div>
<div><br>
</div>
<div>Do you have further comments on the llvm-side patch or the
semantics of the function attribute? Since the last time we
discussed on the list, I've made changes to disallow virtual
functions and objective-c methods to be marked
not_tail_called, which further reduces unpredictability due to
optimization.</div>
<div><br>
</div>
<div>On Tue, Sep 29, 2015 at 5:37 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:
<div class="gmail_extra">
<div class="gmail_quote">
<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">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div> <br>
<br>
<div>On 09/29/2015 11:38 AM, Akira Hatanaka wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Sep 29,
2015 at 10:49 AM, 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 09/28/2015 10:38 PM, Sanjoy Das
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">
<br>
> That was what I had in mind:
the function attribute blocks tail
call for statically direct calls but
doesn't promise<br>
> anything (in fact, does
nothing) for indirect calls.<br>
><br>
> Do you think we shouldn't make
any promises for statically direct
calls either? I don't see why it's
hard to keep the<br>
> promise that direct tail calls
will be blocked. Do you have a
particular optimization in mind that
would be difficult or<br>
> impossible to implement if we
promised to block direct calls?<br>
<br>
I think in this scheme we'll have
problems around devirtualization.<br>
For instance, you could start with a
indirect call to a notail target<br>
that would get TCO'ed (as an
indirect call), after which<br>
devirtualization or load/store
motion would turn the indirect call<br>
into a direct call; and you'd end up
with a direct tail call to a<br>
notail target.<br>
</blockquote>
</span> Sanjoy hits on some of the same
concerns I had with this. In
particular, there's a distinction
between what the language specification
defines as a direct call and what the
optimizer/compiler might turn into a
direct call. At the source layer, we
can *only* make guarantees about the
former. Any specification we write has
to account for the fact the later are an
implementation detail entirely under the
control of the compiler. i.e.
optimizations can not break the
semantics. You have to ensure this when
defining the semantics.</blockquote>
<div><br>
</div>
<div>By "statically direct calls", I meant
the set of calls that can be determined
to be direct at the source level, which
is normally a subset of the calls that
end up being direct calls after all the
optimization passes are run. I agree
that we can probably promise or
guarantee that tail call will be blocked
for direct calls at the source level. We
don't guarantee anything for indirect
calls at the source level.</div>
<div> <br>
</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>
I don't know what your requirements
are, but if I were you I'd design<br>
the `notail` marker to be logically
part of a function's calling<br>
convention. That way functions
marked `notail` get to do things
that<br>
are legal only if the call to them
wasn't a tail call, because all<br>
well-defined calls constrain the
caller to match callee's expectation<br>
with respect to tail calls. In the
CFE, you could make the `notail`<br>
attribute have the same restrictions
/ conventions as things like<br>
`fastcall`.<br>
</blockquote>
</span> I disagree with this slightly.
As I've stated previously, I think there
are two distinct semantics here: a) this
call must be a notail call, and b) we'd
"like" this to be a no tail, but it's
optional. We need to not mix them.<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>
</blockquote>
<div><br>
</div>
<div>The semantics of the tail call marker
I'm looking for is close to b), but
differs in whether we say it's optional
or we guarantee that we block tail call
for a certain subset of calls (direct
calls at the source level). I'm inclined
to have the tail call marker mean
"notail is guaranteed if the call is
direct at the source level", but I
wonder if it'll come back to bite us.</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
I think this is probably fine, but you need someone
with clang/C++ spec knowledge that I don't have to
help with the definition. <br>
<span>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Also, this tail call marker won't be
used to enable optimizations on the marked
function that would be available only if
it were known the call to the function
isn't TCO'ed. That might be an interesting
idea to other people, but it's not
something that is needed for our use case.</div>
<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">
<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">
-- Sanjoy<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>