This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Improved target tuning in simplify-rtx.c
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Thu, 24 Jun 2004 16:27:38 -0700
- Subject: Re: [PATCH] Improved target tuning in simplify-rtx.c
- References: <Pine.LNX.email@example.com> <Pine.LNX.firstname.lastname@example.org>
Roger Sayle wrote:
quality of RTX_COSTS improved. It might come as a shock to some that
the rs6000 backend doesn't provide timing for floating point addition
Defining RTX_COSTS for FP instructions traditionally didn't do anything
useful. If you look at where rtx_costs is used, it is for things like
comparing the costs of two equivalent sequences. This is common in
integer code, where you can use a shift/add sequence or a multiply for
instance. But this is not true for FP code. If you need an FP add,
then you emit an FP add. There is no other alternative, and hence no
need for cost information.
Looking at all of the rtx_cost calls, I see only one that looks vaguely
useful for FP instructions. That is the call in loop-invariant.c. This
is a new code added after the gcc-3.4 branch. So that implies that
defining costs for for FP instructions may be useful post gcc-3.4, but
not before then.
We do need timing info for scheduling. This is very important for FP
instructions. However, the scheduler does not use rtx_cost, and it
never has. The scheduler uses either the new DFA scheduler stuff in the
md file, or the old style define_function_unit stuff. This information
is present in the rs6000 port.
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com