Re: [arm-csl-branch] Updated rtx_costs.

[Richard Earnshaw <rearnsha at arm dot com>]

> Attached is patch with updated rtx_costs for arm926ejs and arm1026ejs cores. 
> The only real difference between these cores and the existing costs seems 
> to be that multiplies are cheaper. Both cores look similar from a relative 
> insn cost POV.
> 
> Basically rtx_cost returns 1 for a single cycle reg op (eg add). A constant 
> pool operand adds a penalty of 4.
> 
> Existing costs for multiplies are comaratively high (8) and depended on the 
> actual value multiplied.
> The 9e/10e cores do SI multiplies in 2/3 cycles and SI*SI->DI mul in 3/4. 
> I've used the smaller of these values on the assumption that the scheduler 
> will usually be able to avoid the 1 cycle interlock with the following 
> insn. DI*DI->DI have a cost of 7 (3+2+2).
> 
> The thumb variant I've given a cost of 4 insns as only the MULS variants are 
> available. The thumb variants seem to use a different costing scale, just 
> to confuse things.
> 
> Ok?
> 
> Paul
> 
> 2003-12-15  Paul Brook  <paul@codesourcery.com>
> 
> 	* config/arm.c (arm_rtx_costs_1): Add MUL costs for arm9e/10e cores.
> 

Sorry, I don't think this is the right way to approach this.  We now have 
fast_multiply and cheap_multiply and it's not at all clear what is what.

Note that your changes are already going to conflict with a change on the 
trunk for XScale multiply costs.

I think the correct thing to do here is to set up a pointer-to-function 
for the multiply cost, which is then initialized from the cpu tuning 
option.  Then we can add support for a processor by writing a suitable 
cost function for it without having to worry about altering the costs for 
other processors.

The only level of debate here should be whether this is done at the full 
rtx_cost level, or at just at the cost-of-a-multiply level.  Ultimately 
the former is probably going to be necessary, but it's probably more work 
than is required right now.

R.