Re: CPROP and spec2000 slowdown in mid february

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    Currently the GCSE and CPROP identifies _much_ more oppurtunities for
    optimization as previously, but due to soomehow crazy try_replace_reg
    implementation throws away most of these.

True, but what I'm confused about is why that change would make things
*worse* since it does identify many more opportunities and uses
slightly *more* of them.  Can you explain the performance regression?

    Basically I've made validate_replace_rtx to work in similar way as
    combine.  To first recurse on parameters and then try simplification
    if some of parameters were clobbered.  Unlike current, somewhat weird
    scheme, this makes us to simplify properly cases, where
    simplifications are nested, so we avoid producing ambiguous RTL, as
    current validate_replace_rtx does.

I was trying to do this in the new functions I (later) added in simplify-rtx.c
and would suggest that those are probably slightly better starting places.
We should keep validate_replace_rtx as just the very simple case meant
to replace one register with another.

    In longer term perhaps even replace combine subst function by this
    beast, if Richard Kenner suceeds with his plan of making combine's
    simplifiers independent on the rest of infrastucture.

That is certainly something I plan to keep working on and may be getting back
to it to take the next step soon.