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

["Daniel Berlin" <dberlin@dberlin.org>]

On 8/1/07, Ayal Zaks <ZAKS@il.ibm.com> wrote:
> "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?
>

Yes.
My only issue here is duplication of code that exists in other passes,
not one of who/when/why things get done.

IE it is easier to use PRE's infrastructure to do the unconditional
load elimination, but still only do more than redundancy elimination
when you will if-convert branches, then it would be to write a new
pass.  Your new pass would end up probably missing loads that PRE goes
to trouble to get, and would duplicate a lot of the safety computation
PRE already knows how to do.

Of course, if you only see yourself moving 1 or two loads per
function, it may be quicker to do just those in their own pass
controlled by ifcvt.  But if you are going to try to if-convert every
branch, and every load inside those branches, you really don't want to
try to make your computation as efficient as PRE makes it.

A similar situation exists for unconditional store sinking/tree-ssa-sink.