This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Improved target tuning in simplify-rtx.c
- From: <tm_gccmail at kloo dot net>
- To: Geert Bosch <bosch at gnat dot com>
- Cc: Roger Sayle <roger at eyesopen dot com>,GCC development group <gcc at gcc dot gnu dot org>
- Date: Wed, 16 Jun 2004 01:35:48 -0700 (PDT)
- Subject: Re: [PATCH] Improved target tuning in simplify-rtx.c
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