Re: An issue for the SC: horrible documentation quality of GCC

[Richard Earnshaw <rearnsha at arm dot com>]

> no -- there are optimizations that are obviously machine-dependent (like
> scheduling, register allocation, peephole, combiner and whole lot of
> others). Then there are optimizations that are based on some general
> machine non-specific idea (like that computing one expression several
> times is wrong, or that replacing variable with its constant value is
> good -- CSE, GCSE, copy/const propagation, part of the loop
> optimizations and some other fall into this cathegory). The sane way
> how to write a compiler is to run these generic passes first, then
> run machine-dependent passes that may eventually fix the mistakes
> the previous optimizations have done (due to their generic ideas being
> not right in some corner cases). This way we would get approximately
> the same results, but in much more transparent way.

I don't believe you can generalize like this.  On a very fast machine with 
a small number of registers it *can* be more efficient to recalculate an 
expression than to keep a copy of a previously evaluated version.

On many ARM implementations a shift by a constant is free in an arithmetic 
operation, so cse'ing

  int *b, *c, d;

  b+=d;
  c+=d;

Which, in RTL is

  (set b (plus (mult d 4) b))
  (set c (plus (mult d 4) c))

into 

  (set t1 (mult d 4))
  (set b (plus t1 b))
  (set c (plus t1 c))

is a de-optimization (takes 3 cycles instead of 2).

R.