Re: [patch] Merge cfo-branch, RTL sequence abstraction (part 1)

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Jan 07, 2006 at 08:48:23AM -0700, Roger Sayle wrote:
> > IMHO the length computation seems better than rtx_cost.
> 
> 
> From the numbers you've provided I'd agree with your conclusions.
> If it's not too much trouble, could you try again with the following
> definition of compute_rtx_cost?
> 
> /* Compute the cost of INSN rtx for abstraction.  */
> 
> static int
> compute_rtx_cost (rtx insn)
> {
>   int cost = insn_rtx_cost (PATTERN (insn));
>   /* If we can't get an accurate estimate for a complex instruction,
>      assume that it has the same cost as a single fast instruction.  */
>   return cost != 0 ? cost : COSTS_N_INSNS (1);
> }
> 
> 
> Your previous implementation of passing the whole "insn" to rtx_cost
> is likely to produce strange values on many backends/instructions as
> the function "rtx_cost" is only intended to handle expressions, such
> as SET_SRC, so shouldn't be used with patterns and certainly not RTL
> insns.
> 
> One reason that using a constant, does so well relatively on the ARM
> is that the ARM backend currently doesn't honor optimize_size, so all
> of the values returned are cycle counts rather than size estimates.

I don't think I understand the reasoning here.  Code factoring is
normally a space optimization; doesn't it make more sense to base
it on lengths than on costs?  Advantages:
  - Useful results when not using -Os, when costs will not be size
    related.
  - Probably more efficient in compile-time - the length is a property
    of the insn rather than having to walk the pattern estimating.

-- 
Daniel Jacobowitz
CodeSourcery