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. > > > Bernd
That might be OK if we didn't have to have standard canonicalization, but I think handling all these special cases would make it incredibly complex and fragile to work out the accurate costs of all these patterns. It's also possible that this would explicitly break some other optimization passes (such as the way in which multiplies are synthesised with shift/add operations). R.
