regclass fix 2

[Jan Hubicka]

> 
> No they don't.  C gets GENERAL, but B still gets FLOAT_INT.
It depends on the -march setting and MOVE_COST.  If they are same in both
directions, both gets GENERAL, as were before my latest REGISTER_MOVE_COST
case.

Here gcc hypotesises that moves INT->FLOAT are expensive dure partial
memory costs and thus preferences FLOAT_INT to avoid worst case.
> 
> >     asm("%0 %1":"=f,r"(c):"f,r"(b));
> >     asm("%0"::"f,r"(c));
> >
> > Both gets FLOAT_INT_REGS.
> 
> Yep, but if you look at the costs listing, it's impossible to tell why:
> 
>   [ Trimmed to the relevant bits ]
>   Register 42 costs: GENERAL_REGS:0 FLOAT_INT_REGS:10 MEM:2
>   Register 43 costs: GENERAL_REGS:0 FLOAT_INT_REGS:22 MEM:6
> 
> It sure looks like we've gone and chosen the most expensive version.
> Can you explain what is happening here?
Sure - the FLOAT_INT_REGS gets calculated by the register_move_costs, that
takes into account possible expensive reg-reg moves inside this class.
So question like "what is the cost to move from FLOAT_REGS to FLOAT_INT_REGS"
is equal to cost of move from FLOAT_REGS to INTEGER_REGS.

Overall costs of such irregular union classes are meaningless for preferencing
and assume worst oppurtunity that register allocator will decide to move
between those subclasses at each instruction.

The preferencing comes from the fact that GENERAL_REGS and FLOAT_REGS both does
have cost of 0 - and thats purpose of my patch.  While choosing preferred
register class, they get unified to FLOAT_INT_REGS.  We don't need the
preferencing information from the unified classes if we have exact enought
information for the subclasses.  I was thinking about way getting these classes
out of listings so they stop confusing people, but I don't have idea how to do
this easilly (ie it means solving kind of set cover problem to figure out
what classes really are meaningless are what not).
> 
> > Looking forward to wipe out those # if this gets accepted!
> 
> A noble goal.
Yep :)
Thanks for reviewing!

Honza