loop optimizations, mark 10

[Richard Henderson <rth at twiddle dot rth dot home>]

Toon, hopefully this addresses most of the problems you were seeing
on m68k.

Highlights of this patch:

  * emit_iv_add_mult records better base address information for
    proper alias analysis. 

    JFC, given that record_base_address is only used by loop, there
    might be a better interface to expose that would handle 
    parallel insns better -- at the moment I'm just using single_set.

  * If ADDRESS_COST is not defined, don't use rtx_cost in its stead.

    This was the primary reason -fforce-addr was losing on m68k.
    That switch guarantees that the existing RTL will use a plain
    register, and any more complicated addressing mode will of
    course cost more, and so not be considered.

    While it would be nice if someone knowledgable about m68k 
    implementations supplied a proper ADDRESS_COST, I'm inclined to
    think that this heuristic is broken anyway, and that the selection
    should be based on other criteria, mostly having to do with register
    pressure.  More thought is required.

  * m68k continually thwarted whatever initial combination heuristics
    I employed, so I ripped all of that out in favour of a brute force
    O(N**2) search.  (Which is still not entirely optimal, given the
    information it currently has.  A more complete search would cost
    {\Sum_i=1^n/2 (2*i)^2} worst case.  But the extra work is almost
    certainly wasted, I think.)

The new combination code still looses on reg+reg addressable targets,
as it tends to decide to combine, e.g.

Insn 74: giv reg 60 src reg 45 benefit 6 used 1 lifetime 5 replaceable
  mult 4 add -4
Insn 97: dest address src reg 45 benefit 11 used 1 lifetime 1 replaceable
  mult 4 add (plus:SI (reg/v/u:SI 29) (const_int -4))

into (plus:SI (reg:SI 88) (reg/v/u:SI 29)).  Which is dumb cause the
first is merely an intermediate expression and isn't otherwise used.

Unfortunately, the giv->times_used data isn't correct, having used the
n_times_used data, which is mis-named and isn't a used count at all,
but a saved set count.  The comment for n_times_data tells you this, 
but I guess the name was so tantilizing it was used to init times_used
anyway.  Use count data is never collected.

But at the moment, even if I had use count data, I'd have to give
more thought to how I'd employ it.  Ho hum.


r~

d-loop-10.gz