I knew I was forgetting something: bootstrapped and tested with no additional regressions on powerpc64-linux-gnu...
On Sun, 2012-03-18 at 20:38 -0500, William J. Schmidt wrote: > On Sun, 2012-03-18 at 18:19 -0700, Andrew Pinski wrote: > > On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt > > <wschm...@linux.vnet.ibm.com> wrote: > > > Greetings, > > > > > > Now that we're into stage 1 again, I'd like to submit the first round of > > > changes for dominator-based strength reduction, which will address > > > issues from PR22586, PR35308, PR46556, and perhaps others. I'm > > > attaching two patches: the smaller (slsr-part1) is the patch I'm > > > submitting for approval today, while the larger (slsr-fyi) is for > > > reference only, but may be useful if questions arise about how the small > > > patch fits into the intended whole. > > > > > > This patch contains the logic for identifying strength reduction > > > candidates, and makes replacements only for those candidates where the > > > stride is a fixed constant. Replacement for candidates with fixed but > > > unknown strides are not implemented herein, but that logic can be viewed > > > in the larger patch. This patch does not address strength reduction of > > > data reference expressions, or candidates with conditional increments; > > > those issues will be dealt with in future patches. > > > > > > The cost model is built on the one used by tree-ssa-ivopts.c, and I've > > > added some new instruction costs to that model in place. It might > > > eventually be good to divorce that modeling code from IVOPTS, but that's > > > an orthogonal patch and somewhat messy. > > > > I think this is the wrong way to do straight line strength reduction > > considering we have a nice value numbering system which should be easy > > to extended to support it. > > Hi Andrew, > > My understanding from earlier discussions with Richard is that strength > reduction within the framework of PRE/FRE has been attempted in the > past, but ran aground on difficulties of globally determining the > profitability of replacements. Profitability is easy to determine when > the stride is constant (all replacements are either harmless or > profitable), but this is not at all the case when the stride has an > unknown but fixed value. (The "fyi" patch contains my logic for > handling this, which is difficult to do with the slightly "myopic" > nature of value numbering.) > > Believe me, my preference is to work within existing passes where > possible, but in this case I was guided by reported past experiences of > others to address this in a new pass. > > Thanks, > Bill > > > > > Thanks, > > Andrew pinski > > > > > > > > > > Thanks, > > > Bill > > > > > > > > > gcc: > > > > > > 2012-03-18 Bill Schmidt <wschm...@linux.vnet.ibm.com> > > > > > > * tree-pass.h (pass_strength_reduction): New decl. > > > * tree-ssa-loop-ivopts.c (add_cost): Remove #undef; rename to > > > add_regs_cost. > > > (multiply_regs_cost): New function. > > > (add_const_cost): Likewise. > > > (extend_or_trunc_cost): Likewise. > > > (negate_cost): Likewise. > > > (get_address_cost): Rename add_cost to add_regs_cost. > > > (force_expr_to_var_cost): Likewise. > > > (get_computation_cost_at): Likewise. > > > (determine_iv_cost): Likewise. > > > * timevar.def (TV_TREE_SLSR): New timevar. > > > * tree-ssa-strength-reduction.c: New. > > > * tree-flow.h (add_regs_cost): New decl. > > > (multiply_regs_cost): Likewise. > > > (add_const_cost): Likewise. > > > (extend_or_trunc_cost): Likewise. > > > (negate_cost): Likewise. > > > * Makefile.in (tree-ssa-strength-reduction.o): New dependencies. > > > * passes.c (init_optimization_passes): Add pass_strength_reduction. > > > > > > gcc/testsuite: > > > > > > 2012-03-18 Bill Schmidt <wschm...@linux.vnet.ibm.com> > > > > > > * gcc.dg/tree-ssa/slsr-1.c: New test. > > > * gcc.dg/tree-ssa/slsr-2.c: Likewise. > > > * gcc.dg/tree-ssa/slsr-3.c: Likewise. > > > * gcc.dg/tree-ssa/slsr-4.c: Likewise. > > > > >
