Re: [new-regalloc-branch]: Bootstrap failure on s390x

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 8 May 2002, Hartmut Penner wrote:

> Thanks, the fix works, and I will take a look for the miscompile...
> Regarding the ragalloc I have some question:
> Are you interested in feedback regarding compiles on the S390 plattform?

Of course.  (Although I know some deficiencies in the allocator which make
it worse than necessary on all platforms.  When integrating it with
web_class and pre-reload this will mostly go away).  But any
miscompilcations due to the allocator I want to know.  Those surely are
not intended but probable ;)

> Is there anything to change in the backend to make better use of the
> register allocator?

Not yet no.  (If the allocator is done, there are possibly some things
which can go away from the machine description, which mostly have to do
with reload.)  But currently there are not enough knobs on the allocator
to fiddle with (from the md/backend I mean.  Changing ra.c is possible of
course ;) )

> Could we help you in any way to get the new code stable?

I'm currently rewriting the representation of the conflict graph (this
doesn't change the grade of stability, though).  Then there's the
integration of web_class and pre-reload (which should also be rewritten
somewhen, it's still based on the reload code base) and to make the
allocator use ra_refs instead df_refs (this is coupled with web_class and
pre-reload).  And of course documentation of the allocator is missing (at
least the big picture).

I.e. other than providing patches for it you could help with testing the
allocator on your platform, and identify miscompilations (to get it
correct is obviously highest priority), preferable with small testcases.
Also identifying stupidity in the decisions of the allocator are
interesting (general or dependant on the platform).  (For instance: One of
the stupidities (a general one) is that when spilling registers the
reloads and stores are extra ld/st insns.  On non-ld/st architectures some
of them can be eliminated, by making the insns for which it was spilled
directly use the stack-slot.  But only in some circumstances this is
profitable due to inference region spilling.)

Faster machines for bootstrapping/testing gcc might also help of course ;)


Ciao,
Michael.