This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: "Ayal Zaks" <ZAKS at il dot ibm dot com>
- Cc: "Dorit Nuzman" <DORIT at il dot ibm dot com>, dpatel at gmail dot com, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, "Michael Matz" <matz at suse dot de>, "Revital1 Eres" <ERES at il dot ibm dot com>, "Tehila Meyzels" <TEHILA at il dot ibm dot com>, trevor_smigiel at playstation dot sony dot com, "Ulrich Weigand" <Ulrich dot Weigand at de dot ibm dot com>, "Victor Kaplansky" <VICTORK at il dot ibm dot com>
- Date: Wed, 1 Aug 2007 15:58:54 -0400
- Subject: Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts
- References: <4aca3dc20708010827k7ff7ba67kfa156d3428eed071@mail.gmail.com> <OFF5121B0E.222D3506-ONC225732A.00642D44-C225732A.0067AE7A@il.ibm.com>
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.