This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] rtx_cost of SUBREG
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org,Mark Dettinger <mdetting at yahoo dot com>
- Date: Sat, 22 Jan 2005 19:57:52 +0100
- Subject: Re: [Patch] rtx_cost of SUBREG
- References: <Pine.LNX.email@example.com>
> 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.
Yes, and I certainly don't mind them as they are not included in the typical
SPARC 64-bit compiler. ;-)
> 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.
Maybe not one, but are you sure of 0 for all targets?
> 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.
Well, it can be reverted after it has been pinpointed, which takes time, that
could have been used to fix higher priority problems.