giv combination patch mark 2

[Richard Henderson]

> I've got some improvements I want to make this evening; perhaps
> I'll find the bug by inspection ...

I did find a bit in which I was using an uninitialized variable,
so maybe I got it.

One current shortcoming in the code is that if it finds eg on m68k

Biv 39 initialized at insn 48: initial value 2
Insn 62: giv reg 52 src reg 39 benefit 6 used 1 replaceable mult 4 add -4
Insn 81: dest address src reg 39 benefit 10 used 1 replaceable mult 4
 add (plus:SI (reg/v/u:SI 29)
    (const_int -4))

the search in combine_givs will not search the raw bivs, and so we get 

        fmove.s %fp0,(%a2,%d1.l)
        addq.l #4,%d1

instead of a potential fmove.s %fp0,(%a2,%d0.l,4).  Hmm, well actually
fmove has a restricted set of modes doesn't it so that was a bad example.
Anyway, the case holds as well for some x86 examples where the modes
are availible.

Anyone know if anything bad would happen if a giv with mult 1 add 0
was added for every biv?  Or, more to the point, why they are kept
separately?

Unchanged from the previous patch is the lack of ability to recognize
indexes through rank 2 dynamic arrays.


r~