This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]