Does gfortran support tail call elimination? - fortran

Question

I made this small program to test, if gfortran does tail call elimination:
program tailrec
implicit none
print *, tailrecsum(5, 0)
contains
recursive function tailrecsum (x, running_total) result (ret_val)
integer, intent(in) :: x
integer, intent(in) :: running_total
integer :: ret_val
if (x == 0) then
ret_val = running_total
return
end if
ret_val = tailrecsum (x-1, running_total + x)
end function tailrecsum
end program
To check, I compiled it with the -S option, to take a look at the instructions. Here the lines for the tailrecsum function:
tailrecsum.3429:
.LFB1:
.cfi_startproc
movl (%rdi), %eax
testl %eax, %eax
jne .L2
movl (%rsi), %eax
ret
.p2align 4,,10
.p2align 3
.L2:
subq $24, %rsp
.cfi_def_cfa_offset 32
leal -1(%rax), %edx
addl (%rsi), %eax
leaq 8(%rsp), %rdi
leaq 12(%rsp), %rsi
movl %edx, 8(%rsp)
movl %eax, 12(%rsp)
call tailrecsum.3429
addq $24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
At the end, I see call tailrecsum.3429 and therefore, think that there is no tail call elimination. This is the same also when I use -O2 or -O3 and -foptimize-sibling-calls.
So, does gfortran not support this or is it a problem of my code?

Answer 1

It does support it. It is quite tricky to avoid many very subtle traps which harm the tail call optimization.
It becomes simpler for the compiler to optimize tail calls if you pass the arguments by value. In that case there is no temporary to which the receiving procedure needs to have a pointer (address).
In fact, this modification is enough to get the tail call elimination and enable unlimited recursion:
recursive function tailrecsum (x, running_total) result (ret_val) bind(C)
integer, value :: x
integer, value :: running_total
integer :: ret_val
if (x == 0) then
ret_val = running_total
return
end if
ret_val = tailrecsum (x-1, running_total + x)
end function tailrecsum
Gfortran does not require the bind(C) because it implements all value as C-like pass by value. Intel does require it because it creates a temporary and passes its address.
The details may differ on different architectures, depending on who is responsible for the cleanup of what.
Consider this version:
program tailrec
use iso_fortran_env
implicit none
integer(int64) :: acc, x
acc = 0
x = 500000000
call tailrecsum(x, acc)
print *, acc
contains
recursive subroutine tailrecsum (x, running_total)
integer(int64), intent(inout) :: x
integer(int64), intent(inout) :: running_total
integer(int64) :: ret_val
if (x == 0) return
running_total = running_total + x
x = x - 1
call tailrecsum (x, running_total)
end subroutine tailrecsum
end program
With 500000000 iterations it would clearly blow the stack without TCO, but it does not:
> gfortran -O2 -frecursive tailrec.f90
> ./a.out
125000000250000000
You can examine what the compiler does more easily using -fdump-tree-optimized. Honestly, I didn't even bother trying to understand your assembly output. X86 assembly is simply too esoteric for me, my simple brain can handle only certain RISCs.
You can see that there is still a lot going on after the call to the next iteration in your original version:
<bb 6>:
_25 = _5 + -3;
D.1931 = _25;
_27 = _18 + _20;
D.1930 = _27;
ret_val_28 = tailrecsum (&D.1931, &D.1930);
D.1930 ={v} {CLOBBER};
D.1931 ={v} {CLOBBER};
<bb 7>:
# _29 = PHI <_20(5), ret_val_28(6)>
<bb 8>:
# _22 = PHI <_11(4), _29(7)>
<bb 9>:
# _1 = PHI <ret_val_7(3), _22(8)>
return _1;
}
I am not an expert in GIMPLE, but the D.193x operations are definitely linked to the temporary expressions that are put on the stack for the call.
The PHI operations then find which version of the return value will be actually returned based on which branch was actually taken in the if statement (https://gcc.gnu.org/onlinedocs/gccint/SSA.html).
As I said it is sometimes tricky to simplify your code to the right form which is acceptable for gfortran to perform the tail call optimization.