Re: [PATCH] Vectorizer cost model outside-cost changes

["William J. Schmidt" <wschmidt at linux dot vnet dot ibm dot com>]

On Tue, 2012-07-24 at 10:57 +0200, Richard Guenther wrote:
> On Mon, 23 Jul 2012, William J. Schmidt wrote:
> 
> > This patch completes the conversion of the vectorizer cost model to use
> > target hooks for recording vectorization information and calculating
> > costs.  Previous work handled the costs inside the loop body or basic
> > block being vectorized.  This patch similarly converts the prologue and
> > epilogue costs.
> > 
> > As before, I first verified that the new model provides the same results
> > as the old model on the regression testsuite and on SPEC CPU2006.  I
> > then removed the old model, rather than submitting an intermediate patch
> > with both present.  I have a patch that shows both if it's needed for
> > reference.
> > 
> > Also as before, I found an error in the old cost model wherein prologue
> > costs of phi reduction statements were not being considered during the
> > final vectorization decision.  I have fixed this in the new model; thus,
> > this version of the cost model will be slightly more conservative than
> > the original.  I am currently running SPEC tests to ensure there aren't
> > any resulting degradations.
> > 
> > One thing that could be done in future for further cleanup would be to
> > handle the scalar iteration cost in a similar manner.  Right now this is
> > dealt with by recording N scalar_stmts, where N is the length of the
> > scalar iteration; as with the old model, there is no attempt to
> > differentiate between different scalar statements.  This results in some
> > hackish stuff in, e.g., tree-vect-stmts.c:record_stmt_cost (), where we
> > have to deal with the fact that we may not have a stmt_info for the
> > statement being recorded.  This is only true for these aggregated
> > scalar_stmt costs.
> > 
> > Bootstrapped and tested on powerpc-unknown-linux-gnu with no new
> > regressions.  Assuming the SPEC performance tests come out ok, is this
> > ok for trunk?
> 
> So all costs we query from the backend even for the prologue/epilogue
> are costs for vector stmts (like inits of invariant vectors or
> outer-loop parts in outer loop vectorization)?

Yes, with the exception of copies of scalar iterations introduced by
loop peeling (the N * scalar_stmt business).

There are comments in several places indicating opportunities for
improvement in the modeling, including for the outer-loop case, but for
now your statement holds otherwise.

Thanks,
Bill

> 
> Ok in that case.
> 
> Thanks,
> Richard.
> 
> > Thanks!
> > Bill
> >