This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH GCC8][14/33]Handle more cheap operations in force_expr_to_var_cost
On Wed, Apr 26, 2017 at 1:58 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 18, 2017 at 12:44 PM, Bin Cheng <Bin.Cheng@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.cheng@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.