my ira review.

[Jeff Law]

Vladimir Makarov wrote:
> 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.
I don't think that eliminating reload in and of itself should be a 
litmus test for a new register allocator.  Instead the question I would 
ask is does the new register allocator make elimination of reload 
easier, harder or is neutral in that regard.

IMHO IRA does not significantly help or hinder the long term goal of 
eliminating reload.

And a strictly personal long term opinion here -- rather than focusing 
on eliminating reload, I'd be happy with seeing a major reduction in the 
size and complexity of reload.  For example, if we could improve things 
so that we didn't rely so heavily on reload to fix things up and in 
those cases where reloads were necessary, we didn't rely so heavily on 
reload-specific optimization passes, then I'd be a happy man.



>> 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.
If we're going to be counting lines of code, then one of the obvious 
things to do is break out those pieces of regmove, local & global which 
  continue to be useful in an IRA world.  Then we can count in a more 
sane manner.

But rather than count lines of code, I'd rather focus on readability and 
understandability of the code -- not just by long term GCC folks, but is 
the code in IRA likely to be understandable by someone with register 
allocation experience.



> I see I should work more on better description of IRA (especially about 
> "I").  So I think the discussion is useful for me.
Agreed.


>> 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.
I wouldn't be surprised if a few things are used elsewhere, or are still 
useful in an IRA world, but yes, the goal should be zapping the vast 
majority of the old register [pre]allocation passes.

I'll also note that IRA seems to eliminate the need for one of the 
proposals for improving local-alloc I was pondering resurrecting back in 
the winter (extending it to work on larger regions).  This is good :-)

jeff