Re: CPROP and spec2000 slowdown in mid february

[Jan Hubicka <jh at suse dot cz>]

> My idea was that sometime you'd want to just do a "lexical"
> substitution without doing any arithmetic simplifications and I'd
> prefer the existing routine keep doing that.  It may well be that all

This is quite consistent with my idea.  I want to keep validate_replace_rtx to
do only the changes on RTX to keep is consistent RTX, as it does current.  For
instance if you replace register by immediate inside zero_extend expression,
you are forced to do the simplification, otherwise you end up with undefined
RTX expression. Validate_replace_rtx should do exactly those simplifications
(and it does now mostly, just few important are omitted and they are sometimes
missed when nested simplifications are required - replacing for instance
(ZERO_EXTEND (SUBREG (REG))) by constant ends up with (ZERO_EXTEND (CONSTANT))).

> the users of that routine will benefit from the simplifications in
> which case they'll all call the new routine and we'll delete the old one.

To simplify given rtx, you will just call the validate_replace_rtx with
simplify_rtx as callback. (in fact, we will probably want to invent new
name for validate_replace_rtx with the callback to keep current one with
current API).

Maybe it really makes sense to delay "aggresive" simplifications. In my
previous experiments this turned out to be neccesary, since certain backends
require insns to be in non-canonical form. This may be considered as bug
in the backend tought.
> 
> This way each caller can be changed as we're sure we want to allow  it to
> make simplifications rather than changing the routine and having all of
> those places "automatically" change: I think it's the more conservative
> approach.

This is also consistent with my idea of keeping validate_replace_rtx do
minimal amount of work.
> 
>     Your implementation IMO does have two problems. Most improtantly it
>     works way to hard doing an extra copy of whole rtx even if there is no
>     single change (by getting everything called trought simplify_*_rtx).
> 
> That's easy to fix if it becomes an issue, but unclear if it's worth
> it now that we have GC.

What I believe to, is that simplify_repalce_rtx implemented a-la
validate_replace_rtx will be both easier and avoid this problem.
Otherwise I probably also would not brother.
> 
>     Second problem is that, as currently implemented, it stops recursing
>     on first unknown element. One I caught was memory expression, but
>     there are many more. Getting it to recurse over generic rtxes is
>     somewhat tricky.
> 
> I don't follow.
The function recurses by calling simplify_gen_* familly of fuctions. When
it reach something that don't have such function, it just stops recursing
and doing substitutions.
This does include the MEM, SUBREG, SIGN_EXTEND and some other RTX constructs
we would probably want to handle.
> 
>     Only think I am affraid of is performance regression of
>     combine. Currently combine spends most time IMO by doing substitutions
>     and these will get much more costy by getting torught memory
>     allocation, memset, re-filling of members etc.
> 
> I don't see that.  Pretty much exactly the same code will be executed, except
> it will live in simplify-rtx.c instead of combine.c.
OK. I believed that you wanted to replace current way of doing substituations
on RTX stream by generating new RTX with modified content, as current simplify_*
functions does.

But I see you may well use the validate_replace_* infrastructure for that and
keep combine about as expensive as it is currently.

Honza