my ira review.

Steven Bosscher
Wed Jul 2 21:07:00 GMT 2008


Vladimir Makarov wrote:
> old RA(regmove, regclass, local-alloc, global, ra-conflict, ra.h) - 10.8K lines
> IRA(ira*.[ch])                                                    - 13.0K lines
> Mike Matz's and others new RA(ra*[ch])                            - 15.4K lines
> Pathscale Global RA                                               - 19.1K of C++
> Mike Matz's RA + pre-reload(pre-reload.[ch])                      - 20.5K lines

This and the other comparisons you make with Matz's allocator don't
make sense to me.  New-ra was not even close to coming out of an
experimental state when it was basically abandoned. But even ignoring
that, new-ra also got rid of most of reload, so your last count should
have been Matz's RA + pre-reload - reload.

Also, for IRA you count only ira*.[ch].  I was under the impression
that IRA still also needs (at least parts of) regmove and local-alloc.
 And IRA adds code to reload and to caller-save, right? That's
another, I don't know, 1000 lines?

Basically, comparing allocators by line counts is not meaningful to
begin with.  I think the complexity of IRA is mostly due to the I in
IRA: Integrated. I have looked at IRA a couple of times now, and I
still have no idea how everything is stringed together.  There is no
textual description of how IRA works that I could understand. Of
course, it doesn't help that it is all new code, and it's not always
clear (at least to me) what is strictly a set of improvements
independent of IRA and what is IRA the allocator sec.

But then again, I can't really say I understand regmove.c either.  Or
actually, I sort of do but don't want to.  Because regmove is really
ugly code.  Same for regclass and the allocator bits in local-alloc.

Can we really remove all regmove and regclass code when IRA is in (and
the whole compiler is changed to work with IRA)?  To those who think
IRA is complex, etc.: At least some other complex, etc. code would go
away then, and I would be very pleased to see regmove go away...


More information about the Gcc-patches mailing list