Re: my ira review.

[Vladimir Makarov <vmakarov at redhat dot com>]

Steven Bosscher wrote:
> xf. http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00147.html
>
> 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.
>
>   
New-ra was not able to work without reload (even for one architecture).  
So I guess (Matz's RA + pre-reload - reload) would be wrong too.
> 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?
>   
Yes, It is about less 700 lines (mostly update_equiv_regs).  But I had 
no time to investigate how much this code is really useful and how can I 
reimplement it in IRA.
> 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.
>   
I agree that lines count is not the best measure of the complexity (and 
I wrote about this) but still a good measure for the size (Kenny wrote 
that IRA is too big).

Yes, it is probably hard to understand.  As I wrote the complexity of 
the problem results in the code complexity.  I had the same problem with 
Patscale allocator and I still have no its overall picture.  Still some 
people understood IRA sufficiently well, I am judging about this by 
patches I got from them.

I see I should work more on better description of IRA (especially about 
"I").  So I think the discussion is useful for me.
> 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...
>
>   
Yes, I am going to work on removing regclass, regmove, local-alloc and 
global.