Re: GCC targets need updating for new register allocator

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:
> The new Integrated Register Allocator is now in GCC trunk, and the old 
> allocator is scheduled for removal on or shortly after 25 September.  All 
> GCC targets need updating for the new allocator; targets that have not 
> been updated when the old allocator is removed will no longer work and 
> will be added to the deprecation list for GCC 4.4.  (After that date 
> target maintainers may remove their targets from the deprecation list as 
> part of the patches updating them for the new allocator; any remaining 
> unconverted targets will be removed from trunk after GCC 4.4 branches 
> along with the other targets deprecated in 4.4.)
>
> Updating a target is a matter of adding an IRA_COVER_CLASSES definition.  
> If you need advice about defining this macro for a target, please ask 
> Vladimir Makarov, not me.  It is of course possible that a target has 
> become bit-rotten in other ways and so needs further fixes to build.  
> Once GCC trunk is building for your target with IRA enabled (with all 
> necessary changes having been committed to GCC trunk), please post test 
> results for unmodified GCC trunk to gcc-testresults if at all possible to 
> provide a record of the current state of that port, if test results for 
> that port are not already being posted reasonably frequently.
>
> The following targets are currently unconverted:
>
> arc
> cris
> crx
> fr30
> frv
> h8300
> iq2000
> m32c
> m32r
> m68hc11
> m68k
> mcore
> mips
> mmix
> pa
> pdp11
> score
> stormy16
> v850
> vax
> xtensa

For the record, I have a WIP MIPS port, and have had for a while.
It got blocked by some IRA wrong-code regressions which I was discussing
with Vlad.  They were caused by incorrect livenes information for EH,
and my "fix" for this was to replace the current note_stores-based
forward scan with a DF-based backward scan, on the basis that using DF
gave us the corrected liveness information "for free".  The problem was
that, although this did indeed fix the wrong-code problem, it showed up
an interesting property of IRA: that it was very sensitive to the order
of numbers given to allocnos.  If you give IRA the same liveness
information, but give allocnos "inverted" numbers, IRA could sometimes
produce much worse results.  (Vlad measured a noticable difference on
SPEC.)

Also, I found what seemed to be a problem with the copy-reduction
heuristics: in certain cases, they could cause us to "deliberately"
pick the one register that would force a copy, even when there was
little register pressure.

Now that IRA is in mainline, I suppose I should move the discussion
on-list.  I'll try to update my notes and experiments for mainline
this weekend and post something to gcc@.

Richard