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:
> But every generic change like this is very likely to uncover latent
> problems.  That's why I think they should not be done at the end of
> stage3.

Again my apologies.  The long history is that back in stage1, I made
several tweaks to combine and the RTL optimizers to more carefully
control the optimizations that were performed based on the target's
rtx_costs.  Almost all of GCC's backends, particularly the well
parameterized ones, immediatetly benefited from this.  Many of the
others soon after tweaked their target's rtx_cost to compensate or
take advantage of these changes; David Edelsohn and I tweaked rs6000,
Eric Christopher tweaked mips, and David Miller updated sparc.

Relatively recently, Mark Dettinger has been doing the same for s390
and s390x and I'm sure you've seen his backend bits on gcc-patches.

I concede that changing the default SUBREG cost, as with any middle-end
change, was riskier.  However, yet again this is a bug-fix that
should benefit most targets (and there was no reason to believe anything
would break).  The cost on acessing these SUBREGs, even on sparc64,
shouldn't been one instruction per operand.  Typically, the register
allocator will place them in a suitable hard register.

In further of my defense, bugs in this part of the compiler are now
fixed almost as soon as they are reported, and correcting the latent
bugs that are often exposed by these perturbations makes for a better
compiler.  At worst, the change can always be reverted.
No harm, no foul?

> A cross is enough, I'll send you a testcase privately.

Many thanks,


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