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

[Roger Sayle]

Hi Daniel,

On Sat, 7 Jan 2006, Daniel Jacobowitz wrote:
> > 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.

I supsect the piece that you are missing is the following paragraph
from the description/definition of TARGET_RTX_COSTS in tm.texi:

    When optimizing for code size, i.e. when optimize_size is
    nonzero, this target hook should be used to estimate the relative
    size cost of an expression, again relative to COSTS_N_INSNS.

This allows target backends to provide size information for their
functionality.  On CISC architectures such as x86, vax, etc...
this is the usual way that this size information is provided to
the middle-end.  In recent years, the "length" insn attribute has
been available for recognized instructions, but rtx_costs is used
early during the compiler to estimate sizes prior to instruction
selection or even RTL expansion.  i.e. rtx_cost(op) should the
speed/size of operation op, even if it isn't representable in a
single instruction.  For example, it encodes the size or duration
of a libcall to libgcc's divdi3 on machines that don't provide
hardware support for DImode division.  Another example, is that
with -Os, synth_mult will generate a synthetic sequence if it is
shorter than a multiply instruction (or libcall).  In many backend
implementations of rtx_cost, a separate table is provided for "size"
as is provided for different architecture families when optimizing
for speed.

rtx_cost is the objective function of a compiler's optimizers.
For embedded targets, where size and code density are important
factors, I'd expect optimize_size handling in rtx_costs to be
well paramterized.

Gabor's current approach of assuming constant length for each INSN_P
in the RTL stream also falls over on non-CISC backends, including ARM,
where many define_insns output multiple instructions. My
predicition/recommendation that insn_rtx_cost become a target hook,
is to allow backends to re-use their length attribute when
available/appropriate.


I hope this helps.

Roger
--