This is the mail archive of the gcc@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]

Register Allocator projects summary


Sorry Im late getting to this, but July was simply insane... 

There was a couple of discussions about register allocation at the GCC
summit, including a dinner hosted by IBM and a BOF afterward.  There may
have been more activity after that, but I wasn't around so I don't know
about it :-).   Someone else can add to this summary in that case.  

This note is just to document the directions that are being taken as a
result.  That way others know whats going on, can offer additional
ideas, or can  help out along the way.  I also don't want to forget what
we talked about :-)  Correct me if I misremember anything :-)

Generally speaking, we all know there are some serious problems with
GCC's register allocator. There have been previous attempts to rewrite
it, there is an ongoing attempt to rewrite it called YARA (makarov), and
I drafted a proposal last fall (RABLE :
http://gcc.gnu.org/ml/gcc/2005-11/msg00783.html) where I laid out what I
thought needed to be done were a new rewrite from scratch to be
attempted..

We came away with 4 primary action points/projects.

1 - Its just getting to the point where maybe we can see where Vlad's
complete rewrite of RA will take us. (branch: yara-branch).  It replaces
everything from regclass to reload, and I believe he is continuing down
the YARA path improving compile time, generated code, and adding
additional targets. I'm sure he would love help :-) 

I don't think anyone else is actually interested in investing the time
and effort into another new RA rewrite from scratch at this point. I
know I'm certainly not.

2 - Thats why I mutated RABLE into RABLET
(http://gcc.gnu.org/ml/gcc/2006-06/msg00736.html). Simply stated, it
attempts to unite the out-of-ssa pass and expand to choose insns with
appropriate register/memory patterns, and combine this with various
register pressure reduction techniques.  The idea is to relieve the
register allocator from having to deal with excessive levels of register
pressure. (ie, 100 registers live at a time).  We discussed what I was
attempting to do and my plan is to go forward with RABLET this fall. I
have cut a branch for some of the initial out-of-ssa rewriting work
(branch: out-of-ssa-the-sequel) and begun that initial work there.

3 - Peter Bergner has been doing some incremental improvements to the
existing RA code, getting it to use less memory, run faster, fixing
warts, and whatever else he sees in there that is fixable and/or
possibly useful by a major rewrite when/if it happens.  I think he also
cut a branch in the not too distant past. (branch: ra-improvements)

4 - It was also concluded that it might be possible to work around the
lack of early instruction selection by writing a pass which would choose
instruction alternatives early for insns.  The later passes would then
be able to see the chosen alternative, and make decisions based on that.
The hope is that this would a) help refine register choices in global
and local allocators and b) prevent reload from undoing a lot of
decisions as it does today.  All without having to undertake a major
rewrite of RA.  At the BOF, Michael Matz thought this sounded like
something he would like to try.  He has also created a branch I believe.
(branch: insn-select)

Those are the 4 actions/projects we left the summit with that I am aware
of.  With any luck at all, one or more of these will have a significant
impact on our register allocator.  Often projects like these proceed in
virtual silence until they are mostly done.  Perhaps I'll try to do a
follow up in a few months to check the progress and results (if any) on
the 4 projects, and post the results as a summary.  Down the road, there
may be some uniting of the work from the various projects, I can see
some potential there...

If anyone is interested in any of these projects, I've identified the
responsible parties above, and you can contact them. If there are any
other suggestions for a project which might also help, by all means let
me know and we can add it to the list.

That's all I remember!  Did I miss anything?

Andrew



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