Does gcc optimize recursive functions? How to do it? [closed] - c++

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I found a interesting quize today about gcc http://ridiculousfish.com/blog/posts/will-it-optimize.html
How come this code
int factorial(int x) {
if (x > 1) return x * factorial(x-1);
else return 1;
}
can be translated by compiler into
int factorial(int x) {
int result = 1;
while (x > 1) result *= x--;
return result;
}
Is this true? How gcc does it?

Answer 1

You already know that gcc can optimize a tail-recursive function into a loop. The other thing that gcc can do (and is mentioned in your link) is try to optimize a non-tail-recursive function into a tail-recursive function.
Your factorial function is here:
int factorial(int x) {
if (x > 1) return x * factorial(x-1);
else return 1;
}
Now I'm going to try to make as few changes as possible and rewrite this as tail-recursive. First, I'll flip the if test:
int factorial(int x) {
if (!(x > 1)) return 1;
else return x * factorial(x-1);
}
Next, I'll remove the unneeded else:
int factorial(int x) {
if (!(x > 1)) return 1;
return x * factorial(x-1);
}
This is almost tail-recursive, but it is returning x * factorial() and not just factorial(). The typical way to make this tail recursive is to include a second parameter, which is an accumulator.
int factorial(int x, int accumulator = 1) {
if (!(x > 1)) return accumulator;
return factorial(x - 1, x * accumulator);
}
Now this is a tail-recursive function, and it can be optimized into a loop.

Answer 2

The compiler could transform that code into something tail-call optimisable by putting the multiplication before the recursive function call:
int factorial(int x) {
return factorial_tail_call(x, 1);
}
int factorial_tail_call(int x, int result) {
if (x > 1) return factorial_tail_call(x-1, result*x);
return result;
}
By performing the evaluation of result*x before factorial_tail_call is called recursively, the compiler can determine that x and result are no longer needed. Hence, it can pop them from the stack. This forms proof that the stack doesn't need to grow.
Can you see any resemblance between the transformed-to code? The 1 is in the same place, the condition x > 1 is in the same place and return result; is in the same place. It's all just a different way of expressing the same algorithm, providing the compiler implements tail call optimisation. By moving the multiplication expression into an argument and putting in comments the code from your post to the right, you might be able to see some resemblance of functionality, and how the compiler managed to make the remainder of the transformation:
int factorial(int x) {
return factorial_tail_call(x, 1); // int result = 1;
}
int factorial_tail_call(int x, int result) {
if (x > 1) return factorial_tail_call(x-1, result*x); // while (x > 1) result *= x--;
return result; // return result;
}
§5.1.2.3p4 of n1570.pdf
In the abstract machine, all expressions are evaluated as specified by
the semantics. An actual implementation need not evaluate part of an
expression if it can deduce that its value is not used and that no
needed side effects are produced (including any caused by calling a
function or accessing a volatile object).
Compilers are smart things, written by far better programmers than most of us. If the compiler can figure out that two pieces of code are equivalent, then it can choose whichever of the two it wishes (with some restrictions, described in the quotation below). For example, it could replace a loop that calculates and prints the first thousand primes with a single printf expression.
§5.1.2.3p6 of n1570.pdf
The least requirements on a conforming implementation are:
— Accesses to volatile objects are evaluated strictly according to the
rules of the abstract machine.
— At program termination, all data written into files shall be
identical to the result that execution of the program according to the
abstract semantics would have produced.
— The input and output dynamics of interactive devices shall take
place as specified in 7.21.3. The intent of these requirements is that
unbuffered or line-buffered output appear as soon as possible, to
ensure that prompting messages actually appear prior to a program
waiting for input.
This is the observable behavior of the program.
That's one reason why micro-optimisation is futile.
If another thread modifyies a string that strlen is processing, that's a race condition. Race conditions are undefined behaviour. You need to guard the string with a mutex to ensure this doesn't happen, or learn better multi-threading paradigms. Which book are you reading?
§5.1.2.4p25 of n1570.pdf
The execution of a program contains a data race if it contains two
conflicting actions in different threads, at least one of which is not
atomic, and neither happens before the other. Any such data race
results in undefined behavior.