GCCJIT and tail-recursive calls

[David Malcolm]

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.