Re: dangerous cleverness? ppc int<->float conversions, subreg

[Geoff Keating <geoffk at geoffk dot org>]

Joern Rennecke <amylaar@onetel.net.uk> writes:

> > The right way to do what you want to do is to change register
> > allocation when this flag is specified, so that it only allocates a FP
> > register as a last resort.
> 
> But that would pessimize fp-heavy code.
> 
> You still have the problem that fpregs usage might seep out of inlined
> functions and never-actually-executed basic block into other basic blocks.
> 
> You'd need not only to make sure that REGISTER_MOVE_COST is high when it
> involves int<->fp reg moves (it already does for the sparc, because it needs
> secondary memory), but also to jack up MEMORY_MOVE_COST so that
> mem -> fpreg -> mem moves won't be generated.
> And fix all the bugs and imperfect heuristics in the compiler that can cause
> it to use fpregs even if the costs say it's not a good choice.

I'm sorry, I wasn't clear.

I didn't mean "tweak the heuristics so that register allocation
prefers not to allocate FP registers".  I meant "change reg-alloc.c so
that when this flag is specified, the register allocator will allocate
a FP register (in a function that does not already have one allocated)
only if there is no choice".

Trying to do this by tweaking machine descriptions will only lead to
pain, suffering, inefficient code, and dozens of bug reports over a
multi-year period, as you discover new and unusual ways that GCC can
decide to allocate a register.

-- 
- Geoffrey Keating <geoffk@geoffk.org>