Re: [PATCH] Reorganize rs6000_rtx_costs

[Roger Sayle <roger at eyesopen dot com>]

On 5 Jul 2004, Geoffrey Keating wrote:
> At the moment, however, such optimization is premature;
> > the rs6000 backend still thinks that "nand" and "nor" require
> > two instructions, ...
>
> Here's a thought.  The .md file already contains all the information
> needed to get a nearly-perfect RTX_COSTS macro in the -Os case.  So
> does the .md file for most other ports.  Would it be possible to use
> that information?

In theory, it might be possible to write a genrtxcosts.c that looked
at both the define_insn's length attribute and even the DFA pipeline
description's latency for an insn's "type" attribute and generated
a default TARGET_RTX_COST for a backend.  However, this approach
would require all backends to be updated to the new DFA pipeline
descriptions, all of them to use the "length" attribute consistently,
and all of the pipeline timings to be at least as accurate as the
currently hand-crafted rtx_cost functions.

I suspect this will eventually be achievable, but there's a lot of
legacy code (machine description) that might need to be cleaned up
first.

I'm also not sure how often the middle-end uses rtx_cost to estimate
the costs of simple RTL that isn't a recognized backend insn pattern.
For example, the cost of PLUS:DI or PLUS:TI which may require a
handful of native instructions.  In these cases "genrecog"-like
machinery alone wouldn't be sufficient.

Roger
--