This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] rtx_cost of SUBREG
- From: Roger Sayle <roger at eyesopen dot com>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 22 Jan 2005 14:41:18 -0700 (MST)
- Subject: Re: [Patch] rtx_cost of SUBREG
On Sat, 22 Jan 2005, Eric Botcazou wrote:
> You haven't answered my question so far: do you think it's unconditionally
> a win for every target (letting aside the MODES_TIEABLE_P thing)?
This is a middle-end default, and as such it only needs to be a win
for the majority of targets. In my review, I pointed out that having
a single constant rtx_cost for a SUBREG across all platforms is less than
desirable, but having that single cost be COSTS_N_INSNS(1) universally
is typically (certainly not uncommonly) wrong.
Given that the cost of zero for a SUBREG is the most appropriate for
the vast majority of SUBREGs on IA-32, as a single popular example,
and AVR, and s390 (and sparc64?)... this would appear to be a win more
often than a loss. If you know of any platform where zero isn't a
reasonable default (or can perhaps even demonstrate a performance
regression), I'd be more than happy to bring forward the plans to
allow backends to specify rtx_cost values for SUBREGs and REGs
themselves.
You could just as well ask is COST_N_INSNS(5) a reasonable default
rtx_cost for multiplication or is COSTS_N_INSNS(7) a reasonable
default for division. Of course, I know lots of platforms where
multiplication isn't 5 times that of addition, but does that make
it a bad default?
Roger
--