[PATCH] Improved target tuning in simplify-rtx.c

[tm_gccmail@kloo.net]

On Tue, 15 Jun 2004, Geert Bosch wrote:

> 
> On Jun 15, 2004, at 12:10, Roger Sayle wrote:
> > As mentioned by Ian Lance Taylor many of these cost values are 
> > heuristic
> > in nature.  The number of "cycles" taken to execute a given instruction
> > depends heavily upon the instructions around it and the state of the
> > pipeline/scheduling group, contents of primary and secondary caches,
> > position within cache-line, register bypasses, hazzards, etc...
> 
> Probably a more realistic cost model would use more than a single
> dimension. Possibilities would be: (latency, throughput, code size,
> register pressure). Latency, throughput and code size should be
> available already and register pressure could be estimated from
> the instruction patterns.
> 
> Then cost is a weighted sum of these axes, where weights may
> differ depending on estimated execution frequency and register
> pressure in a particular basic block.
> 
>    -Geert

This doesn't work either IMHO.

This cost model is predicated on the assumption that you have a
conventional pipelined processor. It breaks if you have any unusual
architectures where you have issues with bundling (IA64) or instruction
grouping (VLIW or DSP architectures) or stack-based architectures,
etc because the cost model is unable to handle unusual constraints.

Also, attempting to evaluate the cost of a single instruction on complex
processors is useless because the executing timing is dependent on the
processor state created by previous instructions.

It makes more sense to evaluate a list of insns instead.

Ideally, you would embed a simple processor simulator in the target.c
file. You would the call the processor model twice; once to evaluate the 
original list of insns and again to evaluate the  modified list of insns
to determine whether the optimization is profitable.

Toshi