Re: Calculation of RTX Costs

[Ian Lance Taylor <iant at google dot com>]

pocmatos@gmail.com (Paulo J. Matos) writes:

> So, from what I understand, it seems that if there is machine
> independent code using COSTS_N_INSNS, I should be using it otherwise
> relative comparisons just don't make sense.
>
> However, from what I can see we have cost hooks for:
> - register move
> - memory move
> - branches
> - rtx
> - address
>
> only the last two refer to the use of COSTS_N_INSNS. How do the
> value for a register move (which defaults to 2), will compare to an rtx
> cost? 

You should be defining your rtx costs with the knowledge that the cost
of a simple register to register move is 2.

> Should we always use COSTS_N_INSNS for all the returned values, or for
> the first 3, COSTS_N_INSNS is applied on the return value?

You should only use COSTS_N_INSNS for RTL patterns that correspond to
complete instructions on your machine.

> This seems to be certainly relevant for when optimising for code size. 
> If I set a specific cost for a register move and a cost for a
> multiplication rtx how are they related?

When optimizing for performance, if your machine can do multiplication
as part of an address calculation, and that multiplication is cheap,
then you would want to make it as cheap as a register to register move.
E.g., on x86, multiplication by 2 or 4 can be cheap.  But in general one
would expect that multiplication would cost more than a register to
register move.  The ratio between the costs should approximate the ratio
of the clock cycles of the relevant instructions, inasmuch as that can
be determined.

When optimizing for size, the cost should normally be the number of
instruction bytes required to implement the operation.

For most processors it's not important to get all costs exactly correct.
The compiler uses the costs in a relatively brute force manner.  If
there is only one way to do some operation, then its cost is irrelevant.
Costs are mainly important on processors like x86 which have several
different ways to implement the same operation.

Ian