Re: [new-regalloc-branch]: pre-reload pass

[Michael Matz <matz at kde dot org>]

Hi,

On 4 Feb 2002, Denis Chertykov wrote:

> I'm agree with you and I'm know about bad design of pre-reload pass,
> but it was an easiest way to implement this pass. Now we can improve it
> infinitely.

Ok.  Then we are on the same line of thinking ;-)

> > I think, that _much_ of the complexity of reload would go
> > away, if done in that way.
>
> Original reload have a many rematerialization things based on insn
> notes.

Right.  That funny inheritance thing is another complexity adder.

> I have removed it. Do you think it's right ? IMHO: new allocator will
> have a rematerialization.

Yep.  It already does for all expressions which are constant and don't
depend on pseudos.  (If expressions depend on pseudos, to rematerialize
them means to possibly extend livetime of those pseudos, which should be
avoided, as the need for remat, i.e spilling, indicated there is already
register pressure.  So those expressions should only be rematerialized, if
all operands are anyway live at the point of rematerialization.  The
mechanism for that is not fully in place yet.)

> >    I want to use rtl
> >    defined addresses (define_address ...) in the future.
> >
> > This seems like a good plan.  Do you already have thought about it some
> > more?
>
> I'm think about it already about two years.

Ohh, I wasn't aware of that.  Very fine.

> You can try to search a gcc@gcc.gnu.org archive for:
> Subject: (define_address ...) suggestions needed
> Date: Tue, 11 Jan 2000 23:25:12 +0300

Found this and some other discussions related to define_address.  Seems to
be an idea since quite some time with reload standing in it's way.  May be
finally we can do something about this.

> One bad thing I lose my archives with implementation of
> define_address.

The positive side is, that the second implementation tends to be nicer
than the first ;-)

> I can describe my thinks about define_address more precisely. If you
> interested.

I am, because the addresses were also a concern for me when thinking about
the pre-allocation validify pass.

> Probably original version of ra.c don't generate abort inside 'combine'
> because you use union of reg_preferred_class and reg_alternate_class.
> reg_alternate_class always GENERAL_REGS or ALL_REGS.

No.  It doesn't abort() because there is an invariant which isn't
violated.  See below.

> But imagine. for_move = 1 and you have a call to sort_and_combine_web_pairs
> and register classes of combining webs are not intersects.

Yes I know, but this can't happen.  In agressive_coalesce() only normal
moves from mv_worklist are added.  This list is filled in
build_worklists() from wl_moves.  wl_moves contains only moves, for which
the hardregs for source and destination intersect (checked in
moves_to_webs(), where non-intersecting moves are cleared in the list).
Therefor the check in sort_and_... is unnecassary when processing pairs
resulting from moves.  Ok, it's only an optimization, so it does no big
harm when double checking.


Ciao,
Michael.