Re: fwprop and CSE const anchor opt

[Adam Nemet <anemet at caviumnetworks dot com>]

Richard Sandiford writes:
> Adam Nemet <anemet@caviumnetworks.com> writes:
> > * Synthesizing multi-insns constants from const anchors make sense regardless
> > whether the constant is used as an address so I am adjusting the cost system
> > to make those stick independent of the context.  I still need to benchmark
> > this.
> 
> Out of interest, what sort of changes did you need to make?  Do you care
> about the cases where rtx_costs is applied to a pattern that won't later
> be checked by recog (such as the calls from the expander)?  Or do you
> just care about the cases where rtx_costs is used to check whether a
> validate_change would be profitable?

I am glad you asked because I myself was going to ask you some questions in
this area ;).

I think the best way to formulate the profitability question for multi-insn
constants in CSE is this.  We found an expression using a const-anchor that is
equivalent to the REG_EQUAL note on the insn.  We go with the const-anchor
expression if it is cheaper than the REG_EQUAL expression.

Comparing the cost of the actual source in the insn against the const-anchor
expression would ignore the fact that the preceding instructions buiding up
the constants become redundant with the const-anchor expression.

I also have an alternative solution that feels more hackish and gives less
control to the backend but works with the current cost model.  For a
multi-insn constant if the current cost and the cost of the new expression are
equal we prefer the new expression.  This works for MIPS because AFAICT we
always replace a binary expression with another one of the same cost.

The problem with the first approach and I feel you were anticipating this with
your question is that multi-insn constants have a cost of zero in the MIPS
backend currently.  Or with the code from mips_rtx_costs:

    case CONST_INT:
[...]
	  /* When not optimizing for size, we care more about the cost
	     of hot code, and hot code is often in a loop.  If a constant
	     operand needs to be forced into a register, we will often be
	     able to hoist the constant load out of the loop, so the load
	     should not contribute to the cost.  */
	  if (!optimize_size
	      || mips_immediate_operand_p (outer_code, INTVAL (x)))
	    {
	      *total = 0;
	      return true;
	    }

That is really hard to beat for an immediate add, which is COSTS_N_INSNS (1).

Since you already offered :), can you please explain where the above code is
needed and whether we can refine the picture a little bit.  It definitely
feels like the above cost value is only true in certain contexts.  This might
be a naive comment but maybe somehow limiting the effect to that particular
context would be a good improvement.

Adam