Richard Sandiford writes:
> Adam Nemet <ane...@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
