This is the mail archive of the gcc-patches@gcc.gnu.org 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: merge from regalloc branch to head [pt2]


Hi,

On Mon, 24 Jun 2002, Bernd Schmidt wrote:

> > The produced code
> > currently is slightly worse to slightly better than with the old
> > allocator.
> [..]
> > The allocator itself is overall much slower than the current
> > one, but often due to optimization passes, which should only be activated
> > on request (e.g. the recoloring of spillnodes is slow as ...).
>
> That doesn't sound too encouraging.  Do you expect that with a bit
> more work the code quality will be significantly better than with the
> current allocator?

Yes.  The current problem in the allocator is, that it doesn't exactly
track the possible register classes for each reference, i.e. only uses the
suggestions from regclass.  As regclass is pseudo-reg based, this leads
sometimes to unnecessary small classas, when splitting webs.  Denis was
working on a webclass pass, which is partly on the branch, but isn't
activated yet.

Another thing is, how spill's are produced.  Currently extra insns are
added to load from/spill to stack slots.  Even if the to-be spilled
register reference is an operand, for which also a mem-ref would be Ok.

I.e. generally dealing with the exact constraints of the insns needs work;
they aren't taken into account at all (besides of what regclass does).
E.g. also matching constraints aren't handled (I have an old patch, which
isn't committed yet).

> A few years ago I was working on a rewrite of reload's inheritance
> code which did seem to help code quality on register-starved machines.
> I abandoned that because it seemed like we wouldn't need it with a new
> register allocator. I'm now wondering whether I should dig it out
> again...

I feel, that reload is a dead end.  The inheritance code is already fairly
complicated, and shouldn't be needed, when the new allocator is able to
fulfill most constraints on it's own.  For instance Denis was able (with a
pre-reload pass) to make reload emit only two reloads for a full gcc
bootstrap.  Currently pre-reload is equally ugly code as reload itself
(it's mostly copied from it), but it's functionality is reimplementable
easier, as it still can deal with pseudo-regs, and doesn't need to do
inheritance.  My plan was (and still is), to get rid of reload altogether,
or at least reduce it to it's bare-bone functionality, to make insns match
their constraints.  Without any optimizations.  But I even think most of
reload can also be reimplemented in context of the new allocator, with
considerable reduction in code size.  I certainly try to do this next.


Ciao,
Michael.


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