Re: [PATCH GCC8][14/33]Handle more cheap operations in force_expr_to_var_cost

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Thu, Apr 27, 2017 at 4:30 PM, Jeff Law <law@redhat.com> wrote:
> On 04/26/2017 06:58 AM, Richard Biener 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.
>
> In an ideal world, we'd have a canoncial form and just handle hte canonical
> form.  But that hasn't ever really panned out for this kind of stuff in RTL
> -- the decision about what is the preferred form of an expression changes
> based on use context.
>
> I don't think these problems are as bad at the gimple level, but clearly
> they still exist.
>
> The more we query the target, the less predictable the compiler's behavior
> will be over time.   It was a huge problem in RTL leading us to a point
> where it became exceedingly difficult to predict how a change in a pass
> would ultimately affect the performance across targets.
Yeah, this is what I had in mind, but not expressed as clear as this.
The patch's intention is to differentiate between expensive (div) and
cheap operations.

Thanks,
bin
>
> That led to a guiding principle that we want to avoid querying the target in
> gimple as much as possible.  We've relaxed that somewhat (we have to be
> pragmatic), but we need to be real careful here.
>
> So my recommendation would be to define a set of costs for gimple and get
> those as solid as we can given an "ideal" target.  Only query the target for
> cases where it's critical.
>
>
> Jeff