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