Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> Most comments, including the second sentence in the head comment
> of combine_validate_cost, the main decision-maker of the combine
> pass, refer to the function as returning true if the new
> insns(s) *cheaper* than the old insns, when in fact the function
> returned true also if the cost was the same.  Returning true for
> cheaper also seems more sane than as-cheap-as considering the
> need to avoid oscillation between same-cost combinations.  Also,
> it makes the job of later passes harder, having combine make
> more complex combinations of the same cost.
>
> Right, you can affect this with your target TARGET_RTX_COSTS and
> TARGET_INSN_COST hooks, but only for trivial cases, and you have
> increasingly more complex combinations (many-to-many
> combinations) where you have to twist simple logic to appease
> combine (stop it from combining) or give up.
>
> Main-interest ports are unsurprisingly pretty tied to this
> effect.  I'd love to install the following patch, adjusting the
> function and the two opposing comments.  But...it causes
> hundreds of regressions for each of x86_64-linux and
> aarch64-linux (tens for ppc64le-linux), so I'm just not up to
> the task, at least not without previous buy-in from reviewers.

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.)

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?

Thanks,
Richard

Reply via email to