RFC: make combine do as advertised (cheaper-than)?

[Hans-Peter Nilsson]

> From: Richard Sandiford <richard.sandiford@arm.com>
> Date: Mon, 6 Jul 2020 11:48:25 +0200

> Out of interest, how do the results change if we still allow the
> combination for equal costs if the new sequence is shorter than
> the original?  I think that still counts as "cheaper than",
> but maybe I'm too RISC-centric. ;-)  (I'm not saying that's
> what we should do, I'm just curious.)

Aha.  I agree to the point I'd say it's a key question and we
should (i.e. if the "speed" cost is the same, inspect again
using size metrics, definitely reject if larger, though
undecided if same).

> Originally combine always produced shorter sequences, so by the
> above reasoning, combining for == was correct.  These days we allow
> N-to-N replacements too, which are obviously a good thing when
> the new cost is lower, but are more of a wash when the costs
> are the same.  But even then, the combination should have a
> "canonicalisation" effect.  (Unfortunately that effect includes
> the result of expand_compound_operation/make_compound_operation.)
> Do you have specific examples of where things go wrong?

I initially thought I had one clear one, but it was an actual bug:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549412.html
which I guess is a point in favor for keeping it same-cost, but
on the other hand, that condition (!i2_was_move && !i3_was_move)
(failing due to wrong value of i3_was_move) is an artificial
measure that would not be needed if same-cost combinations were
rejected.

brgds, H-P