Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts

["Daniel Berlin" <dberlin at dberlin dot org>]

On 8/1/07, Tehila Meyzels <TEHILA@il.ibm.com> wrote:
> "Daniel Berlin" <dberlin@dberlin.org> wrote on 31/07/2007 18:00:57:
>
> >
> > I agree with you for conditional stores/loads.
>
> Great!
>
> >
> > The unconditional store/load stuff, however, is exactly what
> > tree-ssa-sink was meant to do, and belongs there (this is #3 above).
> > I'm certainly going to fight tooth and nail against trying to shoehorn
> > unconditional store sinking into if-conv.
>
> Sometimes, store-sinking can cause performance degradations.
> One reason for that, is increasing register pressure, due to extending life
> range of registers.
>
> In addition, in case we have a store followed by a branch, store sinking
> result will be a branch followed by a store.
> On some architectures, the former can be executed in parallel, as opposed
> to the latter.
> Thus, in this case, it worth executing store-sinking only when it helps the
> if-conversion to get rid of the branch.
>

> How do you suggest to solve this problem, in case store-sinking will be
> part of the tree-sink pass?
>
Store sinking already *is* part of the tree-sink pass. It just only
sinks a small number of stores.
The solution to the problem that "sometimes you make things harder for
the target" is to fix that in the backend.  In this case, the
scheduler will take care of it.

All of our middle end optimizations will sometimes have bad effects
unless the backend fixes it up.    Trying to guess what is going to
happen 55 passes down the line is a bad idea unless you happen to be a
very good psychic.

As a general rule of thumb, we are happy to make the backend as target
specific and ask as many target questions as you like.  The middle
end, not so much.  There are very few passes in the middle end that
can/should/do ask anything about the target.  Store sinking is not one
of them, and I see no good reason it should be.

> Another point, what about (unconditional) load hoisting:
> It's surely not related to sink pass, right?
>
PRE already will hoist unconditional loads out of loops, and in places
where it will eliminate redundancy.

It could also hoist loads in non-redundancy situations, it is simply
the case that it's current heuristic  does not think this is a good
idea.

Thus, if you wanted to do unconditional load hoisting, the thing to do
is to make a function like do_regular_insertion in tree-ssa-pre.c, and
call it from insert_aux.

We already have another heuristic for partially antic fully available
expressions, see do_partial_partial_insertion