Re: SPECfp95: Huge performance loss with -fnew-ra?

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 24 Jul 2002, Diego Novillo wrote:

> > > No, it's the new-ra, i'm sure.
> >
> > Me too ;)
> >
> OK.  Any ideas why the new allocator seems to have almost no
> effect on integer code?  Is it the same problem?

Most probably the spill code.  On non-load/store architectures (like x86)
it's better to place the mem's for stack-slots directly into the place of
the spilled operands.  Unfortunately that's not done currently.  Instead
an explicit load (or store) insn is added.  This isn't a problem for
load/store arch's, because there it's anyway the only possibility to
load/store from/to memory.

I.e.  given p1 <= p2 + p3, and p2 spilled it currently generates:
  p2' <= [slot(p2)]
  p1 <= p2' + p3

We need an additional register (p2') here, but if operand 1 allows mem it
should directly generate
  p1 <= [slot(p2)] + p3.

This should be conditionalized on the fact, that we don't need [slot(p2)]
soon again (this is prepared already), and that the insn is still valid
then (so that we don't need reloads).  The infrastructure for this is in
the works.

Another problem can be assignments of pseudos to a too broad regclass, so
that later for some insns reloads are needed.  The deeper reason for both
problems is the same, namely precise tracking of constraints.

But given the crappy way of producing spill code, I'm actually happy that
it at least produces code, which isn't that much slower.


Ciao,
Michael.