<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 09/29/2015 11:38 AM, Akira Hatanaka
wrote:<br>
</div>
<blockquote
cite="mid:CAB297QxOqXqbs6BTj_=j1_Er7jU4s5G4EwKQdY=NPgNKCK=65g@mail.gmail.com"
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:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 09/28/2015 10:38 PM, Sanjoy Das wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc 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:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc 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:0 0 0
.8ex;border-left:1px #ccc 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>
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>
<blockquote
cite="mid:CAB297QxOqXqbs6BTj_=j1_Er7jU4s5G4EwKQdY=NPgNKCK=65g@mail.gmail.com"
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:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
-- Sanjoy<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>