Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition

[Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>]

Hi Bernd,

On 15/12/15 14:22, Bernd Schmidt wrote:
> On 12/14/2015 01:25 PM, Kyrill Tkachov wrote:
>> PR 68651 is a code quality regression for GCC 5 and GCC 6 that was
>> introduced due to updated rtx costs
>> for -mcpu=cortex-a53 that affected expansion.  The costs changes were
>> correct (to the extent that rtx
>> costs have any meaning) and I think this is a deficiency in combine that
>> should be fixed.
>
> Thinking a bit more about this, I'm actually not sure that this isn't a backend problem. IMO the costs could and maybe very well should be represented such that a left shift by 1 and an add have the same cost, and the insn pattern for the 
> shift should emit the add if it is cheaper. If there are multiple ways of expressing an operation, then how it is represented in RTL is essentially irrelevant to the question of how much it costs.
>

Then for the shift pattern in the MD file we'd have to dynamically select the scheduling type depending on whether or not
the shift amount is 1 and the costs line up?
Sounds like going out of our way to work around the fact that either combine or recog does not understand equivalent forms
of instructions.

I'd be more inclined to follow your suggestion in your first reply (teaching genrecog about equivalent patterns)
However, I think that would require a bit more involved surgery in recog/combine whereas this approach
reuses the existing change_zero_ext approach which I feel is less intrusive at this stage.

The price we pay when trying these substitutions is an iteration over the rtx with FOR_EACH_SUBRTX_PTR.
recog gets called only if that iteration actually performed a substitution of x + x into x << 1.
Is that too high a price to pay? (I'm not familiar with the performance characteristics of
the FOR_EACH_SUBRTX machinery)

Thanks,
Kyrill

>
> Bernd
>