Re: [PATCH] Fix PRE of TARGET_MEM_REF

[Richard Guenther <rguenther at suse dot de>]

On Sun, 31 May 2009, Dorit Nuzman wrote:

> > On Tue, May 26, 2009 at 1:12 PM, Revital1 Eres <ERES@il.ibm.com> wrote:
> > >
> > > Hello,
> > >
> > > I wonder if there is any objection to also schedule predictive
> commoning
> > > after the vectorizer, like in the following patch.
> > > Scheduling predcom ?and PRE passes after the vectorizer could help to
> solve
> > > PR39300, ?among others.
> > > I am planning to do SPEC runs with this patch for testing.
> >
> 
> great. this is the main thing that has held back scheduling predcom after
> vectorization
> 
> > What we should do for predictive commoning is to run its analysis
> > phase before (or inside?) the vectorizer and just handle it in the
> > vectorizer cost model.  I expect that for small vector sizes
> > (for example v2df) predictive commoning is often more effective
> > than vectorization, especially if the loop is memory bound.
> >
> 
> I don't think it's the vectorizer's job to evaluate the impact of
> predictive commoning or any other optimization... hopefully if loop-count
> is too small the cost model will figure out that we shouldn't vectorize
> regardless of other optimization alternatives. Also, we could try to
> vectorize efficiently, taking advantage of the data reuse while we
> vectorize (we do it in other situations in the vectorizer).

Well, I think we should have a centralized cost-model for the various
loop optimizations.  Running

  predcom-analysis
  vectorizer-analysis
  cost-model
  vectorizer / predcom

is one way to make sure we do not disable predictive commoning
by vectorizing or the other way around if the other transformation
is more profitable.

After some more thoughts I would consider doing PRE before ivopts,
because the extra redundancy removal should improve its decisions.

We should probably do PRE on scalar code parts (simply not
phi-translate over back-edges) early, during the first FRE run.

Richard.