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

+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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150917/a08f549e/attachment.html>

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-dev/attachments/20150921/c61deb44/attachment.html>

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-dev/attachments/20150922/23634da1/attachment.html>