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

[Akira Hatanaka via llvm-commits]

OK, I'll wait a few more days so that others can look at and comment on the
patch.

On Wed, Nov 4, 2015 at 2:36 PM, Philip Reames <listmail at philipreames.com>
wrote:

> I have no further comments.  All of my points from previous discussion
> stand, but it sounds like you have addressed those.
>
> Philip
>
>
> On 11/04/2015 01:23 PM, Akira Hatanaka wrote:
>
> I've been discussing the clang-side patch and making changes based on the
> feedback I got for the last few weeks. Aaron has reviewed the patch and he
> thinks it's OK now.
>
> http://reviews.llvm.org/D12922
>
> Do you have further comments on the llvm-side patch or the semantics of
> the function attribute? Since the last time we discussed on the list, I've
> made changes to disallow virtual functions and objective-c methods to be
> marked not_tail_called, which further reduces unpredictability due to
> optimization.
>
> On Tue, Sep 29, 2015 at 5:37 PM, Philip Reames <listmail at philipreames.com>
> wrote:
>
>>
>>
>> On 09/29/2015 11:38 AM, Akira Hatanaka wrote:
>>
>> On Tue, Sep 29, 2015 at 10:49 AM, Philip Reames <
>> listmail at philipreames.com> wrote:
>>
>>>
>>>
>>> On 09/28/2015 10:38 PM, Sanjoy Das wrote:
>>>
>>>>
>>>> > That was what I had in mind: the function attribute blocks tail call
>>>> for statically direct calls but doesn't promise
>>>> > anything (in fact, does nothing) for indirect calls.
>>>> >
>>>> > Do you think we shouldn't make any promises for statically direct
>>>> calls either? I don't see why it's hard to keep the
>>>> > promise that direct tail calls will be blocked. Do you have a
>>>> particular optimization in mind that would be difficult or
>>>> > impossible to implement if we promised to block direct calls?
>>>>
>>>> I think in this scheme we'll have problems around devirtualization.
>>>> For instance, you could start with a indirect call to a notail target
>>>> that would get TCO'ed (as an indirect call), after which
>>>> devirtualization or load/store motion would turn the indirect call
>>>> into a direct call; and you'd end up with a direct tail call to a
>>>> notail target.
>>>>
>>> Sanjoy hits on some of the same concerns I had with this.  In
>>> particular, there's a distinction between what the language specification
>>> defines as a direct call and what the optimizer/compiler might turn into a
>>> direct call.  At the source layer, we can *only* make guarantees about the
>>> former.  Any specification we write has to account for the fact the later
>>> are an implementation detail entirely under the control of the compiler.
>>> i.e. optimizations can not break the semantics.  You have to ensure this
>>> when defining the semantics.
>>
>>
>> By "statically direct calls", I meant the set of calls that can be
>> determined to be direct at the source level, which is normally a subset of
>> the calls that end up being direct calls after all the optimization passes
>> are run. I agree that we can probably promise or guarantee that tail call
>> will be blocked for direct calls at the source level. We don't guarantee
>> anything for indirect calls at the source level.
>>
>>
>>>
>>>
>>>> I don't know what your requirements are, but if I were you I'd design
>>>> the `notail` marker to be logically part of a function's calling
>>>> convention.  That way functions marked `notail` get to do things that
>>>> are legal only if the call to them wasn't a tail call, because all
>>>> well-defined calls constrain the caller to match callee's expectation
>>>> with respect to tail calls.  In the CFE, you could make the `notail`
>>>> attribute have the same restrictions / conventions as things like
>>>> `fastcall`.
>>>>
>>> I disagree with this slightly.  As I've stated previously, I think there
>>> are two distinct semantics here: a) this call must be a notail call, and b)
>>> we'd "like" this to be a no tail, but it's optional. We need to not mix
>>> them.
>>>
>>>>
>>>>
>> The semantics of the tail call marker I'm looking for is close to b), but
>> differs in whether we say it's optional or we guarantee that we block tail
>> call for a certain subset of calls (direct calls at the source level). I'm
>> inclined to have the tail call marker mean "notail is guaranteed if the
>> call is direct at the source level", but I wonder if it'll come back to
>> bite us.
>>
>> I think this is probably fine, but you need someone with clang/C++ spec
>> knowledge that I don't have to help with the definition.
>>
>>
>> Also, this tail call marker won't be used to enable optimizations on the
>> marked function that would be available only if it were known the call to
>> the function isn't TCO'ed. That might be an interesting idea to other
>> people, but it's not something that is needed for our use case.
>>
>>
>>> -- Sanjoy
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151104/f4c884c8/attachment.html>