[PATCH] D12923: Add support for function attribute "notail"
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 24 13:53:24 PDT 2015
On 09/24/2015 01:47 PM, Akira Hatanaka wrote:
> On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> 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 <mailto: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".
>
>
> OK. I'm considering changing the direction of this patch and marking
> the call site instead of the called function.
>
> We should also discuss what kinds of source level attributes we'll
> need. My plan is to attach an attribute that indicates notail
> (something like no_direct_tail) to the called function declaration and
> definition and then mark all the direct call sites in the IR that call
> the function as notaill. In addition to that, it seems like we want to
> have a way to attach the attribute directly to the call site:
>
> void (*indirectCall)(int, int, int);
>
> void foo1(int a, int b) {
> (*indirectCall)(a, b, c) __attribute__((notail));
> }
I think you're going to want to have the same dichotomy between (1) and
(2) at the source level as in the IR. The same issues apply in both cases.
>
>>
>> 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/20150924/5371708a/attachment.html>
More information about the llvm-commits
mailing list