preexpand_calls vs. TARGET_EXPRs

Geoff Keating
Sat Oct 21 19:00:00 GMT 2000

Mark Mitchell <> writes:

>   (f () + 1) + (g (), 8)
> we pre-evaluate the calls to `f' and `g' before expanding the
> I'm not sure exactly what the point of that it is.  It doesn't seem to
> be for correctness (unless there's something about the
> ever-troublesome do_pending_stack_adjust -- and in that case there's
> probably still a bug since preexpand_calls doesn't expand builtins,
> even though they can sometimes result in actualy function calls).
> Therefore, I assume it's some attempt at optimization.  (If so, it's
> probably misguided; we should be depending on real algorithms to
> reorder code, not playing games during tree-expansion.)

I expect much of the time it's a de-optimisation.  For instance, given
a() + b() + c(), if you evaluate it as

t1 = a();
t2 = b();
t3 = c();
t1 + t2 + t3

you're using one more call-saved register than is necessary for

t1 = a();
t2 = b();
t1 = t1 + t2;
t3 = c();
t1 + t3;

(It probably also schedules better the second way, because you have
more instructions between the calls and so the processor gets more
time to prefetch the instructions of c().)

So if there are no correctness problems---and IMO any correctness
problems should be fixed in another way than by doing this---I'd
recommend taking it out.

- Geoffrey Keating <>

More information about the Gcc-bugs mailing list