Re: preexpand_calls vs. TARGET_EXPRs

[Jeffrey A Law <law at cygnus dot com>]

  In message <jmpukt7i02.fsf@envy.cygnus.com>you write:
  > Mark Mitchell <mark@codesourcery.com> writes:
  > 
  > >   (f () + 1) + (g (), 8)
  > > 
  > > we pre-evaluate the calls to `f' and `g' before expanding the
  > > PLUS_EXPR.
  > > 
  > > 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.
FWIW, I believe both GVN+GCM paper presents an algorithm for expression
evaluation ordering.  They might provide some insights into how to reorder
expression evaluation to improve code (though I believe they were based on
reordering to expose loop invariants and common subexpressions.

jeff