RFD: rtx_cost changes

A while ago I posted this:
> Our rtx_costs infrastructure is somewhat inadequate.  Consider
> reload_cse_move2add, which converts constant loads into add
> instructions.  We have the following problems:
> 
> 1. There's no way to distinguish between a 3-operand operation and a
>    2-operand operation in rtx_costs.  On Thumb-2,
>    movs r2, #100
>    adds r2, r2, #8
>    adds r2, r3, #7
>    are 2-byte instructions, while
>    movs r8, #100
>    movw r2, #3095
>    add r2, r2, #1234
>    add r2, r3, #8
>    take four bytes.  If we only have (plus (r3) (const_int 8)) or
>    (const_int 100), we cannot meaningfully return a cost for it.  We
>    need to know the SET_DEST.
> 2. When optimizing for speed, we should prefer faster instructions, but
>    when choosing between equally fast alternatives, we should pick the
>    smaller one.  The same applies vice versa when optimizing for size.
> 3. We have no way of estimating costs for a strict_low_part load of a
>    constant (one optimization done in reload_cse_move2add).
> 4. rtx_costs returns zero for REG, even when outer_code == SET.  This is
>    almost certainly wrong everywhere; COSTS_N_INSNS (1) seems like a
>    better choice.  This isn't addressed yet in the patch, as trying to
>    change it introduces lots of changes in code generation.
> 5. In postreload, we have apples-to-oranges comparisons of the form
>    rtx_cost (x, PLUS) < rtx_cost (y, SET)
>    which makes no sense.  A constant may well be free inside a PLUS,
>    but the insn still has a cost which we'd underestimate in such a
>    case.  We should compare both in terms of outer_code == SET.
> 6. On some machines, using constants is better than using registers.
>    reload_cse_simplify_operands doesn't have a plausible cost check
>    when substituting constants, and reload_cse_move2add should also
>    do the substitution only when costs improve.  It's likely that
>    further optimization passes can more easily deal with a constant
>    load rather than an add, and on OOO machines it may reduce
>    dependencies between instructions and reduce the number of
>    register accesses in a cycle (documented as a limitation of PPro
>    and its derivatives such as Core 2).

The previous patch was unnecessarily large.  I realized that the problem
can be solved without a rtx_cost interface change if the callers pass
whole SETs to rtx_costs, so I've modified code in postreload to do
exactly this.  I still think we'll want to think about the interface at
some point.

The patch below addresses problems #1, #2 and #5 (and #6 as far as
move2add is concerned).  I've bootstrapped and regression tested this on
i686-linux and verified that the new ARM testcase passes.  I've removed
ARM-specific costs changes and for now since they caused some
undesirable effects even though they were more correct than the current
code.

Ok for the rtl.h/rtlanal.c bits?

Bernd
* postreload.c (move2add_use_add2_insn): Use full_costs for
	comparison.
	(move2add_use_add3_insn): Likewise.
	(reload_cse_move2add): Likewise.
	* rtlanal.c (get_full_rtx_cost): New function.
	* rtl.h (struct full_rtx_costs): New.
	(init_costs_to_max, init_costs_to_zero, costs_lt_p,
	costs_add_n_insns): New inline functions.
	(get_full_rtx_cost): Declare.

	* gcc.target/arm/pr40457-3.c: New test.

RFD: rtx_cost changes

Commit Message

Comments

Patch