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

[Ayal Zaks <ZAKS@il.ibm.com>]

"Daniel Berlin" <dberlin@dberlin.org> wrote on 01/08/2007 18:27:35:

> 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.
>

Hoisting a non-redundant load speculatively above an if may indeed be a bad
idea, unless that if gets converted as a result (and possibly even then
...).  Are we in agreement then that unconditional load/store motion for
the sake of redundancy elimination continues to belong to PRE/tree-sink,
and that conditional load/store motion for the sake of conditional-branch
elimination better be coordinated by if-cvt?

Ayal.

> 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