[llvm-dev] [PATCH] D12923: Add support for function attribute "notail"

Wed Sep 23 11:22:51 PDT 2015

I think option #1 would be useful for "correctly" emitting calls to dladdr;
 it wants to be able to walk up the stack to find what shared object it was
called from.

On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On 09/23/2015 08:48 AM, Akira Hatanaka wrote:
>
> On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames <listmail at philipreames.com>
> wrote:
>
>> 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.
>>
>>
> 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.
>
> If it's not simply best effort, that constrains our choices.
>
>
>
>> 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.
>>
>
> 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.
>
> 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.
>
>
>
>> 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.
>>
>
> 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.
>
> (This only applies if we're talking about a function annotation.  The call
> site annotation applies to both direct and indirect calls.)
>
>
>
>>
>> 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.)
>>
>
> 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.
>
> 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.
>
> Yep.
>
>
>
>> 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?
>>
>>
> 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.
>
> 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:
> - "notail" - Can not be a tail call.
> - "" - May be a tail call if analysis finds it legal, profitable, and
> desirable*
> - "tail" - May be a tail call, profitability hinted
> - "musttail" - Must be a tail call.
>
> * (2) would basically just change the desirability of moving from "" to
> "tail".
>
>
> Philip
>>
>>
>> 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 time.
>>
>> 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>llvm-commits at lists.llvm.org> wrote:
>>
>>> +llvm-dev
>>>
>>> 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.
>>>
>>> Philip
>>>
>>>
>>> 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:http://reviews.llvm.org/D12922
>>> http://reviews.llvm.org/D12923
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing listllvm-commits at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>>
>>
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150923/50bf1a68/attachment.html>