On Wed, Apr 26, 2017 at 1:58 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Apr 18, 2017 at 12:44 PM, Bin Cheng <bin.ch...@arm.com> wrote: >> Hi, >> This patch handles more cheap cases in function force_expr_to_var_cost, >> specifically, >> TRUNC_DIV_EXPR, BIT_AND_EXPR, BIT_IOR_EXPR, RSHIFT_EXPR and BIT_NOT_EXPR. >> >> Is it OK? > > I wonder if using add_cost is good here. TRUNC_DIV by power of two > better matches > shift_cost, no, or div_pow2_cheap? Likewise for LSHIFT/RSHIFT. We do > have [us]div_cost as well btw. > And we have neg_cost. > > I mean if we're going all the way of using target based costs in > force_expr_to_var_cost rather > than estimate_num_insns then we should do as good as we can? I tend to believe it doesn't matter much. We can do experiments in the future. On the contrary, more generalization/abstraction might be good here so that we only need to measure cost by number of simple alu operations. And existing code uses add_cost rather than neg_cost for negate_expr. One argument for general cost is, in general, cost computed by force_expr_to_var_cost will be amortized by loop niter. As for induction related computation, add/sub/scale/mult are the most common operations anyway.
Thanks, bin > > Richard. > > >> Thanks, >> bin >> 2017-04-11 Bin Cheng <bin.ch...@arm.com> >> >> * tree-ssa-loop-ivopts.c (force_expr_to_var_cost): Handle more >> operators: TRUNC_DIV_EXPR, BIT_AND_EXPR, BIT_IOR_EXPR, RSHIFT_EXPR >> and BIT_NOT_EXPR.