RE: [Patch][AVR]: Support tail calls

["Boyapati, Anitha" <Anitha dot Boyapati at atmel dot com>]

>
>Boyapati, Anitha schrieb:
>
>> To be on same page, can you explain how gcc optimizes above case?
>
>in
>
>void bar0 (void);
>int bar1 (int);
>
>int foo (int x)
>{
>    bar0();
>    return bar1 (x);
>}
>
>x must be saved somewhere. avr-gcc choses Y.
>Compiled -Os -mmcu=atmega8 -fno-optimize-sibling-calls reads

Ok. I was trying to understand the basic strategies of handling a tail-called function. Broadly speaking,

[1]. In the case of normal tail-call, the stack of the caller is freed and then a jump to callee is made.
[2]. Incase of a tail-recursive case, the recursion is made iterative.


>gcc recognizes most cases where tail call optimization must not be
>applied. But in some cases backend has to impose more restrictions,
>this is what TARGET_FUNCTION_OK_FOR_SIBCALL is for. E.g. An ISR must
>not tail-call an ordinary function because the epilogues must be
>compatible bit ISR resp. non-ISR have incompatible epilogues.
>


<snip>

>
>As with all other optimization options/passes, they are only applied
>in the presence of optimization, i.e. with -O0 options like
>-foptimize-sibling-calls have no effect. You will have to specify at
>least -O1 to see effects.
>

Thanks. I tried various cases (mutually recursive functions, interrupts and signals, variable arguments). Required a bit of wandering through tree-tailcall.c to know what other cases are not qualified as tail-called ones(variable arguments is one such). The code generated is as expected.

Coming to -mcall-prologues issue, I agree whenever prologue_saves and epilogue_restores, making the function qualified as a tail call is not ok (or it requires different handling). Going by the backend code, they are now emitted (prologue_saves and epilogue_restores) whenever -mcall-prologues is used. Ditto when callee-used registers are used for argument passing.


I think it is a nice work!


Anitha