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

[Richard Biener]

On Thu, Apr 27, 2017 at 5:45 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> 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.

Ok.  Let's go with the patch as-is then and if possible change the code
to use estimate_num_insns instead (but I guess we may end up comparing
the cost to the address costs we compute more exactly?)

Richard.

> 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