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

[Akira Hatanaka via llvm-commits]

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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150921/c61deb44/attachment.html>