Re: New Regalloc Branch

[Erwin Ingris <erwiningris at yahoo dot com dot au>]

Hi,

> On Mon, 27 May 2002, Michael Matz wrote:
> 
> > I noticed that GCC is going to have a new-register
allocator.
> > However I could not find out why? or what are the
> known deficiencies
> > with existing register allocator. Could the
> community enlighten me!!
> 
> The current allocator (which really works in three
> passes) doesn't work
> really globally, and the algorithms it uses are
> failry adhoc.

Yeah, I noticed it.It calls, local_alloc, global_alloc
and reload seperately. 
Just a curiosity,why did developers chose this route
in the first place?  

>  It can't
> split pseudo registers, or coalesce them (although
> it has something like
> preferences to get rid of copies, which is something
> like coalescing).

I think regmove pass would  also be achieving a 
similar functionality.After all it is also eliminating
reg-to-reg copies.

> It doesn't use exact live-ness information to the
> full extent. And
> spill-code is inserted by a different pass (reload),
> which means it can't
> be taken into account by the allocator.  To not
> produce bad code, reload
> has wonderfull and big chunks of code, making it
> barely maintainable.

Yup !! It is just horrible to look at 
LEGITIMIZE_RELOAD_ADDRESS macros.

> Of course it's also fun to write a register
> allocator for something
> with such diverse needs like gcc's architectures ;)

Oh definitely, after all many volunteers in FSF
work for sheer fun thrill.(to the
frustration of proprietry software vendors ;-)
(Just a remark ;-) 
 
> > and I am also curious about when it will be in a
> position to bootstrap
> > for other ports except x86 and ppc-linux.
> 
> It once bootstrapped also on alpha and sparc.  I'm
> currenly looking why
> it doesn't anymore (on ppc, s390x, alpha and sparc).

New register allocator is definitely a big-big change
in GCC backend.For diversity of architectures that 
gcc supports, I wonder when it will be able to
mainline.(any gueses from ur side).

Meanwhile I am also curious about performance
improvements on supported ports .
 
> > (and if I want to help, can some one roughly tell
> me how to do it)
> 
> checkout the branch, and figure out how and where it
> does miscompile your
> favourite sources S (although it compiled correctly
> with -fno-new-ra),
> simplify it to a small testcase T, and send that to
> me.  Bonus points if S
> is gcc itself on a different architecture than x86
> (currently I'm fighting
> with alphaev67 and powerpc), for the bootstrap. ;) 
> Even more points for
> also providing a patch which fixes the problem.  
>But
> for that you need a
> fairly good understanding of ra.c, which isn't
> exactly easy sometimes,

Well I will asking too many questions then ;-)

I have played around with gcc code before.
I have time these days to do it again 
and possibly contribute something this time
But even if I get engrossed elsewhere some useful
discussion should be archived on mailing list.
And I do want to gather some points atleast ;-)

BTW if people on the list could point out 
specific reg-alloc problems, they might be 
taken care while testing new one.If they
are alrady somewhere I think there can be 
a link to that info somewhere.

Regards,
Erwin.

-------------------------------------------------------
There is nothing more powerful than the idea whose
time
has come.
-------------------------------------------------------

http://travel.yahoo.com.au - Yahoo! Travel
- Plan and book your dream holiday online!