<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 24, 2015 at 4:34 PM, Philip Reames <span dir="ltr"><<a 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">
<div text="#000000" bgcolor="#FFFFFF"><div><div>
<br>
<br>
<div>On 09/24/2015 03:04 PM, Akira Hatanaka
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Sep 24, 2015 at 1:53 PM,
Philip Reames <span dir="ltr"><<a 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">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div> <br>
<br>
<div>On 09/24/2015 01:47 PM, Akira Hatanaka wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Sep 23, 2015
at 11:13 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank"></a><a 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">
<div text="#000000" bgcolor="#FFFFFF"><span>
<br>
<br>
<div>On 09/23/2015 08:48 AM, Akira
Hatanaka wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue,
Sep 22, 2015 at 8:31 AM,
Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank"></a><a 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">
<div text="#000000" bgcolor="#FFFFFF"> To be
clear, this is a debuging
aid only? It's not
something required for
correctness? I'm somewhat
bothered by that because
it seems like it would be
a useful implementation
tool for higher level
languages. <br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>It's not purely a
debugging aid that helps
when you are using the
debugger. There are projects
(that are not debuggers)
that rely on not missing
frames to produce results
that are useful.</div>
</div>
</div>
</div>
</blockquote>
</span> If it's not simply best effort,
that constrains our choices. <br>
<span>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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">
<div text="#000000" bgcolor="#FFFFFF"> A
couple of thoughts in no
particular order:<br>
1) Can we always annotate
the call site rather than
the function? That
removes the
unpredictability due to
optimization.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Annotating the call site
should be fine. For the use
cases that we care about, it
probably isn't important to
prevent tail calls on
indirect calls.</div>
</div>
</div>
</div>
</blockquote>
</span> Given this, I would lean towards
a notail value being added as an
alternative to "tail" and "musttail".
This seems to fit the existing uses,
doesn't have any obvious loop holes or
best effort semantics, and solves the
problem at hand. <br>
<span>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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">
<div text="#000000" bgcolor="#FFFFFF"> 2)
Calling it something like
"no-direct-tail-call" or
"prefer-no-tail" would
remove some of the
confusion value. When I
see "notail", I expect
that to always be
respected; the best effort
semantics come as a bit of
a surprise.</div>
</blockquote>
<div><br>
</div>
<div>I agree. A name that
indicates it's only a best
effort option or it's an
option that affects only
direct calls would be good.</div>
</div>
</div>
</div>
</blockquote>
</span> (This only applies if we're
talking about a function annotation.
The call site annotation applies to both
direct and indirect calls.)<span><br>
<blockquote 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">
<div text="#000000" bgcolor="#FFFFFF"> <br>
3) This seems analogous to
the "tail" marker in that
it indicates a
preference/option.
Whatever we end up with,
it needs to be a verifier
option to have a "tail" or
"musttail" call site which
is also "notail". It also
needs to be an error to
have a mustail callsite to
a notail function (if such
ends up existing.)<br>
</div>
</blockquote>
<div><br>
</div>
<div>If we are going to
annotate the function, I
think we should have the
verifier catch
incompatibilities between
the markers on the call
sites and the function
attribute on the called
functions.</div>
<div><br>
</div>
<div>If we are annotating the
call site, the verifier
check isn't needed since the
tail-call related markers
are enums that are mutually
exclusive.</div>
</div>
</div>
</div>
</blockquote>
</span> Yep.<span><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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">
<div text="#000000" bgcolor="#FFFFFF"> 4) It
somewhat feels like there
are two concepts being
intermixed here. 1) A
call site which will never
be a tail call. 2) A
function which we prefer
not to tail call to. Does
it make sense to separate
them?<span><font color="#888888"><br>
<br>
</font></span></div>
</blockquote>
<div><br>
</div>
<div>Yes, it makes sense to
separate them. For the use
case we care about, either
1) or 2) will do. We don't
have to have support for
both.</div>
</div>
</div>
</div>
</blockquote>
</span> I would lean toward doing (1)
for now. We can come back and implement
(2) at a later time if we find it's
needed. After (1), each call site will
have four states:<br>
- "notail" - Can not be a tail call.<br>
- "" - May be a tail call if analysis
finds it legal, profitable, and
desirable*<br>
- "tail" - May be a tail call,
profitability hinted<br>
- "musttail" - Must be a tail call.<br>
<br>
* (2) would basically just change the
desirability of moving from "" to
"tail". <br>
<div>
<div> <br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>OK. I'm considering changing the
direction of this patch and marking the
call site instead of the called function.</div>
<div><br>
</div>
<div>We should also discuss what kinds of
source level attributes we'll need. My
plan is to attach an attribute that
indicates notail (something like
no_direct_tail) to the called function
declaration and definition and then mark
all the direct call sites in the IR that
call the function as notaill. In addition
to that, it seems like we want to have a
way to attach the attribute directly to
the call site:</div>
<div><br>
</div>
<div>void (*indirectCall)(int, int, int);</div>
<div><br>
</div>
<div>void foo1(int a, int b) {</div>
<div> (*indirectCall)(a, b, c)
__attribute__((notail));<br>
</div>
<div>}</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
I think you're going to want to have the same dichotomy
between (1) and (2) at the source level as in the IR.
The same issues apply in both cases. <br>
</div>
</blockquote>
<div><br>
</div>
<div>I think you were suggesting we always annotate the call
site rather than the function. Are you suggesting we do
the same thing at the source level, i.e. allow marking the
call site but not the function? I have to confirm, but I
believe the people who requested this feature wanted to
use a function attribute rather than marking each call
site that calls the target function.<br>
</div>
</div>
</div>
</div>
</blockquote></div></div>
What I'm suggesting is that the function attribute should be a best
effort semantic. If we can tell something is a direct call, we
should avoid the tail call, but we don't guarantee to never emit a
tail call to the function in question. If you need an absolutely
guarantee that a particular call (even if indirect) will not be a
tail call, you'd need to mark the call site. <br>
<br>
(In practice, the "prefer_no_tail" function attribute will probably
work pretty reliability, but I'm concerned about "promising" that it
will work. Doing so for a subset of calls (i.e. "statically direct
calls") and may work for others is somewhat defensible, but I've
learned not to make promises the optimizer has a hard time keeping.
Does the distinction make sense?)<div><div><br></div></div></div></blockquote><div><br></div><div>That was what I had in mind: the function attribute blocks tail call for statically direct calls but doesn't promise anything (in fact, does nothing) for indirect calls.</div><div><br></div><div>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 promise that direct tail calls will be blocked. Do you have a particular optimization in mind that would be difficult or impossible to implement if we promised to block direct calls?</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"><div text="#000000" bgcolor="#FFFFFF"><div><div><br><blockquote type="cite"><div dir="ltr"><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><blockquote type="cite"><div dir="ltr"><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><blockquote type="cite"><div dir="ltr"><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"><span><font color="#888888">
Philip</font></span>
<div>
<div><br>
<br>
<div>On 09/21/2015
06:22 PM, Akira
Hatanaka wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Several
users have
been asking
for this
function
attribute to
prevent losing
the calling
functions's
information in
the backtrace.
If we attach
the attribute
to a function,
ideally we
would want to
prevent tail
call
optimization
on all call
sites that
call the
function.
However, the
compiler
cannot always
tell which
function is
called from a
call site if
it's an
indirect call,
so it's fine
if an indirect
call to the
marked
function ends
up being
tail-call
optimized. For
direct calls,
we want the
function
attribute to
prevent tail
call 100% of
the time.</div>
<div><br>
</div>
<div>We can also
use a "notail"
marker on the
call
instruction
instead of
using a
function
attribute. The
only downside
of using a
marker is that
we probably
will never be
able to
prevent tail
call
optimization
on indirect
calls even
when the
compiler can
turn it into a
direct call
(for example,
via inlining).
I'm not sure
at the moment
how important
this is.</div>
<div><br>
</div>
<div>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote">On
Thu, Sep 17,
2015 at 9:47
AM, Philip
Reames via
llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank"></a><a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</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">
<div text="#000000" bgcolor="#FFFFFF">
<div>+llvm-dev<br>
<br>
Can you give a
bit of
background on
what you're
trying to
address here?
After reading
through the
discussion and
seeing that
this is a best
effort flag,
I'm not sure
that a
function
attribute is
the best way
to describe
this. I'm
open to being
convinced it
is, but I'd
like to hear a
bit more about
the use case
and get
broader
visibility on
the proposal
first.<br>
<br>
Philip
<div>
<div><br>
<br>
On 09/16/2015
07:27 PM,
Akira Hatanaka
via
llvm-commits
wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<pre>ahatanak created this revision.
ahatanak added a subscriber: llvm-commits.
This patch adds support for a new IR function attribute "notail". The attribute is used to disable tail call optimization on calls to functions marked with the attribute.
This attribute is different from the existing attribute "disable-tail-calls", which disables tail call optimizations on all call sites within the marked function.
The patch to add support for the corresponding source-level function attribute is here:
<a href="http://reviews.llvm.org/D12922" target="_blank">http://reviews.llvm.org/D12922</a>
<a href="http://reviews.llvm.org/D12923" target="_blank">http://reviews.llvm.org/D12923</a>
Files:
docs/LangRef.rst
include/llvm/Bitcode/LLVMBitCodes.h
include/llvm/IR/Attributes.h
include/llvm/IR/Instructions.h
lib/AsmParser/LLLexer.cpp
lib/AsmParser/LLParser.cpp
lib/AsmParser/LLToken.h
lib/Bitcode/Reader/BitcodeReader.cpp
lib/Bitcode/Writer/BitcodeWriter.cpp
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
lib/IR/Attributes.cpp
lib/IR/Verifier.cpp
lib/Transforms/Scalar/TailRecursionElimination.cpp
test/Bindings/llvm-c/Inputs/invalid.ll.bc
test/Bindings/llvm-c/invalid-bitcode.test
test/Bitcode/attributes.ll
test/Bitcode/invalid.ll
test/Bitcode/invalid.ll.bc
test/CodeGen/X86/attr-notail.ll
test/Transforms/TailCallElim/notail.ll
</pre>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
llvm-commits mailing list
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
llvm-commits
mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank"></a><a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank"></a><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>