From: Jason Merrill <jason@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Basile Starynkevitch <basile@starynkevitch.net>,
Jeff Law <law@redhat.com>, David Malcolm <dmalcolm@redhat.com>,
gcc-patches List <gcc-patches@gcc.gnu.org>,
jit@gcc.gnu.org
Subject: Re: [PATCH 0/3] Support for mandatory tail calls
Date: Fri, 01 Jan 2016 00:00:00 -0000 [thread overview]
Message-ID: <CADzB+2mxf5ss9r4V=i5auM6DjqW64APwYnUz5be=UG_SCQ2i7A@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc3TeiVeUVnOpzk-HK7uSBTPHAcEHNp+ULOPKXzcDzGqLQ@mail.gmail.com>
On Thu, May 19, 2016 at 9:28 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, May 19, 2016 at 3:19 PM, Jason Merrill <jason@redhat.com> wrote:
>> On Thu, May 19, 2016 at 12:30 AM, Basile Starynkevitch
>> <basile@starynkevitch.net> wrote:
>>> On 05/19/2016 12:12 AM, Jeff Law wrote:
>>>>
>>>> On 05/17/2016 04:01 PM, David Malcolm wrote:
>>>>>
>>>>> There have been requests [1] for libgccjit to better support
>>>>> functional programming by supporting the contination-passing style,
>>>>> in which every function "returns" by calling a "continuation"
>>>>> function pointer.
>>>>>
>>>>> These calls must be guaranteed to be implemented as a jump,
>>>>> otherwise the program could consume an arbitrary amount of stack
>>>>> space as it executed.
>>>>>
>>>>> This patch kit implements this.
>>>>>
>>>>> Patch 1 is a preliminary tweak to calls.c
>>>>>
>>>>> Patch 2 implements a new flag in tree.h: CALL_EXPR_MUST_TAIL_CALL,
>>>>> which makes calls.c try harder to implement a flagged call as a
>>>>> tail-call/sibling call, and makes it issue an error if
>>>>> the optimization is impossible. It doesn't implement any
>>>>> frontend support for setting the flag (instead using a plugin
>>>>> to test it). We had some discussion on the jit list about possibly
>>>>> introducing a new builtin for this, but the patch punts on this
>>>>> issue.
>>>>
>>>> I wonder if we should have an attribute so that the flag can be set for
>>>> C/C++ code. I've seen requests for forcing tail calls in C/C++ code several
>>>> times in the past, precisely to support continuations.
>>>
>>> Why an attribute? Attributes are on declarations. I think it should better
>>> be some pragma like _Pragma(GCC tail cail, foo(x,y)) or some builtin (or
>>> else some syntax extension like goto return foo(x,y); ...) because what we
>>> really want is to annotate a particular call to be tail-recursive.
>>
>> C++11 attributes can apply to expression-statements as well, e.g.
>>
>> [[gnu::tail_call]] fn();
>>
>> though not to sub-expressions.
>
> That's nice. Can they apply to things like loops?
>
> [[gnu::no_unroll]] for (int i=0; i<4; ++i)
> a[i] = 0;
Yes, to any statement.
Jason
prev parent reply other threads:[~2016-05-19 13:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-01 0:00 David Malcolm
2016-01-01 0:00 ` [PATCH 2/3] Implement CALL_EXPR_MUST_TAIL_CALL David Malcolm
2016-01-01 0:00 ` Jeff Law
2016-01-01 0:00 ` Andreas Schwab
2016-01-01 0:00 ` [PATCH] Fixes to must-tail-call tests David Malcolm
2016-01-01 0:00 ` Rainer Orth
2016-01-01 0:00 ` Thomas Preudhomme
2016-01-01 0:00 ` David Malcolm
2016-01-01 0:00 ` Jeff Law
2016-01-01 0:00 ` [PATCH 2/3] Implement CALL_EXPR_MUST_TAIL_CALL Andreas Schwab
2016-01-01 0:00 ` [PATCH 1/3] Introduce can_implement_as_sibling_call_p David Malcolm
2016-01-01 0:00 ` Jeff Law
2016-01-01 0:00 ` Kyrill Tkachov
2016-01-01 0:00 ` [PATCH] calls.c: fix warning on targets without REG_PARM_STACK_SPACE David Malcolm
2016-01-01 0:00 ` [PATCH 3/3] jit: implement gcc_jit_rvalue_set_bool_require_tail_call David Malcolm
2016-01-01 0:00 ` Trevor Saunders
2016-01-01 0:00 ` David Malcolm
2016-01-01 0:00 ` [PATCH 0/3] Support for mandatory tail calls Jeff Law
2016-01-01 0:00 ` Basile Starynkevitch
2016-01-01 0:00 ` Jason Merrill
2016-01-01 0:00 ` Richard Biener
2016-01-01 0:00 ` Jason Merrill [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADzB+2mxf5ss9r4V=i5auM6DjqW64APwYnUz5be=UG_SCQ2i7A@mail.gmail.com' \
--to=jason@redhat.com \
--cc=basile@starynkevitch.net \
--cc=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jit@gcc.gnu.org \
--cc=law@redhat.com \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).