Re: [PATCH, ARM] Avoid using VFP registers for SImode

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Wed, 2005-01-05 at 15:01, Daniel Jacobowitz wrote:
> On Wed, Jan 05, 2005 at 11:30:54AM +0000, Richard Earnshaw wrote:
> > Not sure if this really counts as a bug, but VFP support is new in
> > gcc-4, so this can't introduce a regression.
> > 
> > On ARM processors with VFP floating point, using the VFP registers for
> > integer values (except when we are about to convert them into floating
> > point values) is a bad idea.  However, GCC is far too keen to try this
> > when register pressure starts to increase.  This patch fixes this by
> > hiding the VFP register classes from the register preferencing pass.
> > 
> > Tested on arm-elf with VFP enabled.
> 
> Ah, that's a fix I hadn't thought of...
> 
> I noticed a similar case at -O0 last week.  The reason in my testcase that
> regclass is so eager to try this is here:
> 
> enum reg_class
> {
>   NO_REGS,
>   FPA_REGS,
>   CIRRUS_REGS,
>   VFP_REGS,
>   ...
> 
> At -O0 regclass uses the cheapest class for "best" and the first class
> it sees that is better than memory for "alt", so "alt" is almost always
> VFP_REGS.  Maybe the costs need adjustment if memry should be preferred
> to VFP_REGS.

I don't think it's as simple as just adjusting the costs (though it
might help).  What is really wanted is a rule that says:

Don't use VFP regs at all for SImode, unless you've already *had* to use
them for something else in this function.

Why, well there are two invisible costs associated with the registers.
1) Saving them (unless you can use scratches)
2) Context switching times (especially for lazy context switching of the
register banks)

There was also an issue with the old code where if a pseudo that was
being converted to a floating point value had to be reloaded, the only
alternatives that could do this were forbidden to reload (I assume in an
attempt to stop it using fp regs for spills); the change reverses that
policy and makes them available for that purpose, but it seems that the
compiler will not do that very often if the original preferred class was
GENERAL_REGS.

R.