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

[Philip Reames via llvm-commits]

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 
a surprise.
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?

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 <mailto: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 list
>>     llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
>     _______________________________________________
>     llvm-commits mailing list
>     llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150922/23634da1/attachment.html>