From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56610 invoked by alias); 10 Jul 2015 01:39:21 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 56597 invoked by uid 89); 10 Jul 2015 01:39:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Message-ID: <1436491885.31573.17.camel@surprise> Subject: Re: GCCJIT and tail-recursive calls From: David Malcolm To: Basile Starynkevitch Cc: jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: <559EF605.3060102@starynkevitch.net> References: <559EF605.3060102@starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-SW-Source: 2015-q3/txt/msg00070.txt.bz2 On Fri, 2015-07-10 at 00:30 +0200, Basile Starynkevitch wrote: > Hello all, > > It is well known that GCC is sometimes able to optimize some calls to > tail-recursive calls (or tail calls > https://en.wikipedia.org/wiki/Tail_call ...) which do not consume any stack. > > can a GCCJIT application issues such tail calls? I'm not talking of > letting GCC decide entirely by itself (GCCJIT is probably doing that > already). gcc (and thus libgccjit) can already decide by itself if a call is a tail-call, and optimize accordingly. See: https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#behind-the-curtain-how-does-our-code-get-optimized and in particular: https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#elimination-of-tail-recursion This is done by: gcc/tree-tailcall.c controlled by: -foptimize-sibling-calls which is on by default at -02 and above. Normally you'd do something like: gcc_jit_block_end_with_return (... gcc_jit_context_new_call (...)); or gcc_jit_block_add_eval (... gcc_jit_context_new_call (...)); gcc_jit_block_end_with_void return (...); The tailcall is obvious in both of these cases. > I was thinking of adding a construct where the GCCJIT client knows > for sure that the call should be tail-rec (and if GCCJIT was not able to > make a tailcall, that would be an error). It's not clear to me why that would be useful. Am I missing something? > Also, even without optimization (i.e. at -O0) that should remain a > tailcall... Can't you simply turn on -foptimize-sibling-calls at -O0? > Perhaps adding a gcc_jit_block_end_with_tail_call function? I can see a way of implementing it for tail-recursion (via a goto), though it would complicate the implementation (and hence I'm not keen); I can't see way of doing it for the more general case of tail calls.