CRIS: Make rtx-cost 0 for many CONST_INT "quick" operands
commit68982b98d2a7a52cfc5aada7d35d6c493c010712
authorHans-Peter Nilsson <hp@axis.com>
Wed, 29 Mar 2023 22:56:13 +0000 (30 00:56 +0200)
committerHans-Peter Nilsson <hp@bitrange.com>
Wed, 29 Mar 2023 22:56:13 +0000 (30 00:56 +0200)
tree079b93ce956cc6de2a9bc3f2aba453787d617dd0
parent3be4e43a6a0f429648ea188c8e110b74268fed27
CRIS: Make rtx-cost 0 for many CONST_INT "quick" operands

Stepping through a gdb session inspecting costs that cause
gcc.dg/tree-ssa/slsr-13.c to fail, exposed that before this
patch, cris_rtx_costs told that a shift of 1 of a register
costs 5, while adding two registers costs 4.

Making the cost of a quick-immediate constant equal to using
a register (default 0) reflects actual performance and
size-cost better.  It also happens to make
gcc.dg/tree-ssa/slsr-13.c pass with what looks like better
code being generated, and improves coremark performance by
0.4%.

But, blindly doing this for *all* valid operands that fit
the "quick-immediate" addressing mode, trips interaction
with other factors*, with the end result mixed at best.  So,
do this only for MINUS and logical operations for the time
being, and only for modes that fit in one register.

*) Examples of "other factors":

- A bad default implementation of insn_cost or actually,
pattern_cost, that looks only at the set_src_cost and
furthermore sees such a cost of 0 as invalid.  (Compare to
the more sane set_rtx_cost.)  This naturally tripped up
combine and ifcvt, causing all sorts of changes, good and
bad.

- Having the same cost, to compare a register with 0 as with
-31..31, means a compare insn of an eliminable form no
longer looks preferable.

* config/cris/cris.cc (cris_rtx_costs) [CONST_INT]: Return 0
for many quick operands, for register-sized modes.
gcc/config/cris/cris.cc