Re: [RFA] The Integrated Register Allocator

[Bernd Schmidt <bernds_cb1 at t-online dot de>]

Vladimir Makarov wrote:
> IRA is not a default register allocator.  To switch it on, option
> -fira should be used.  IRA is currently implemented only for
> x86/x86_64/ppc/itanium/sparc/arm/s390.  For all other targets, the
> compiler will issue a warning for -fira and will use the old register
> allocator as previously.

I don't want this email to be interpreted as negative - this is probably 
really cool work.  I just don't think this submission contains enough 
information for us to evaluate whether to commit it to trunk or not.

What is needed to make a target work?  Is it just the COVER_CLASSES 
definition, or are there other reasons why IRA might not support a target?

Do we plan to keep the old allocator, or is IRA sufficiently superiour 
that we can just add COVER_CLASSES to all ports and delete global.c? 
Are there cases where we could expect IRA to produce better/worse code 
than the old allocator due to a given target's architecture (e.g. 
two-operand vs three-operand, small register classes vs. large ones, 
regular vs irregular register file, special purpose registers, etc.)?

What role does reload still play with IRA?  Does IRA leave less invalid 
RTL for reload to fix up - if so, could the latter be simplified?

There should be performance data, both in terms of compiler 
runtime/memory usage, and effect on the generated code.

Should there really be this many new options?  Is it useful or confusing 
for users to have that many tunables?  If we do leave the switches in, 
what set of options do we recommend?

Is this a monolithic block of code, or can some smaller pieces be split 
off to go in first?

Also - and I know this is a battle I've lost on other occasions - for a 
patch adding some 12000 lines of code, there is very little high-level 
overview, both in terms of structure and algorithms used in new code 
(which I'd like to see in the code), and in terms of how it interacts 
with existing code.  Essentially, I don't think a ChangeLog is 
sufficient, I'd much rather see a patch submission contain a verbal 
description of the most important changes in the patch.


Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif