Re: Is -fnew-ra ready for real testing?

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Michael Matz writes:

Michael> I'm not sure, if the allocator in mainline will change too much, partly
Michael> because the feature freeze.  Bug fixes and smaller adjustments will be
Michael> made, though, so you can just send me a preprocessed file to matz@suse.de,
Michael> which exhibits such behaviour (and if you even have some dumps from the
Michael> profiler, all the better ;) ).  I can't promise to make it really faster
Michael> though (except switching off such obvious time takers like
Michael> recolor_spills()), as some of the infrastructure is still missing even in
Michael> the regalloc branch.

	Because new-ra is not the default register allocator for GCC 3.3,
I think that you have a little more latitude to make performance
improvements and "fix" things that are localized to the "ra" files, at
least up until the GCC 3.3 branch.

	I also think that we need to step back and make sure we have the
correct expectations from the new register allocator.  The new register
allocator generally does a great job of generating ideal register
colorings *when that is possible*.  The new register allocator is not a
magic cure for all of the other GCC problems related to registers -- it
cannot prevent other mistakes like register pressure and spill code.

	On benchmarks I have run using architectures with many GPRs, the
new register allocator has been able to find a much better allocation
producing repeatable performance improvements of up to 51% on one
example.  YMMV.  When the new register allocator has the flexibility to do
better, it does much better, but it cannot work miracles.

	The new register allocator was merged into the mainline for
greater exposure and testing.  Are there remaining bugs and performance
problems and examples of particularly bad behavior? Undoubtedly.  Can
those and will those problems be fixed by the release of GCC 3.3?
Unknown.

David