[PATCH] D12923: Add support for function attribute "notail"
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 22 08:31:53 PDT 2015
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.
A couple of thoughts in no particular order:
1) Can we always annotate the call site rather than the function? That
removes the unpredictability due to optimization.
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
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.)
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?
On 09/21/2015 06:22 PM, Akira Hatanaka wrote:
> 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
> 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.
> On Thu, Sep 17, 2015 at 9:47 AM, Philip Reames via llvm-commits
> <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
> 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.
> On 09/16/2015 07:27 PM, Akira Hatanaka via llvm-commits wrote:
>> 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:
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
> llvm-commits mailing list
> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits