IRA has been merged into trunk

[Jeff Law]

Vladimir Makarov wrote:
> In worst case (I think the worst case will be MIPS targets), there may 
> be several variants of the macro definition.  In such cases it is hard 
> to say what variant will be best with the performance point of view 
> without some analysis.  Unfortunately, choice of the variants can not 
> be algorithmized, otherwise I'd have rid off the macro.  If target 
> maintainers have any questions about IRA_COVER_CLASSES definition, I 
> am ready to help them.  I am ready to look at all their target macro 
> definitions.
I suspect MIPS will be a pain, mostly because of the testing requirements.

I expect the PA to be somewhat painful because of oddities in how we 
support xmpyu and the dbra class of insns.

I expect the m68k to potentially stumble over some of the same problems 
as the mn103 -- specifically around partial word values in ADDRESS_REGS 
-- it's likely we'll be twiddling constraints and/or defining more 
secondary reload cases.  Testing will also be painful unless someone's 
got a m68k simulator handy.

I've nailed down the latent mn103 bug (missing secondary reload for 
am33-2 FP loads/stores), but I'm still stumbling over some problems with 
-O0 C++ code which manifest themselves as testcases stomping over 
malloc's datastructures.   Luckily I've been able to trigger them with 
malloc debug enabled, so it ought to be a little easier to nail them down.

I've got H8 bits in testing right now.

NickC beat me to a bunch of the embedded targets (v850, m32r, fr30, 
iq2000, mcore).

Jeff