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
