Patch 10/9: track subwords of DImode allocnos

[Bernd Schmidt <bernds at codesourcery dot com>]

So here's the scary part.  This adds ALLOCNO_NUM_OBJECTS and the
possibility that it may be larger than 1.  Currently, it only tries to
do anything for two-word (i.e. DImode) allocnos; it should be possible
(and even relatively easy) to extend, but I'm not sure it's worthwhile.
 Whether even this version is worthwhile is for others to decide.

I should explain what I've done with the conflict handling.  Given two
DImode allocnos A and B with halves Ah, Al, Bh and Bl, we can encounter
four different conflicts: AhxBl, AhxBh, AlxBh and AlxBl.  Of these, only
three are meaningful: AhxBh and AlxBl can be treated equivalently in
every place I found.  This reduces the number of ways two such allocnos
can conflict to 3, and I've implemented this (as "conflict
canonicalization") by recording an AlxBl conflict instead of a AhxBh
conflict if one is found.  This is meaningful for functions like
setup_allocno_left_conflicts_size: each of these three conflicts reduces
the number of registers available for allocation by 1.

There are some places in IRA that use conflict tests to determine
whether two allocnos can be given the same hard register; in these cases
it is sufficient to test the low-order objects for conflicts (given the
canonicalization described above).  Any other type of conflict would not
prevent the allocnos from being given the same hard register (assuming
that both will be assigned two hard regs).

There is one place in the code where this canonicalization has an ugly
effect: in setup_min_max_conflict_allocno_ids, we have to extend the
min/max value for object 0 of each multi-word allocno, since we may
later record conflicts for them that are due to AhxBh and not apparent
at this point in the code.

Another possibly slightly ugly case is the handling of
ALLOCNO_EXCESS_PRESSURE_POINTS_NUM; it seemed easiest just to count
these points for each object separately, and then divide by
ALLOCNO_NUM_OBJECTS later on.

The test for conflicts in assign_hard_reg is quite complicated due to
the possibility Jeff mentioned: the value of hard_regno_nregs may differ
for some element regs of a cover class.  I believe this is handled
correctly, but it really is quite tricky.

Even after more than a week of digging through IRA, I can't claim to
understand all of it.  I've made sure that all the places I touched
looked sane afterwards, but - for example - I don't really know yet what
ira_emit is trying to do.  There may be bad interactions.

Still, successfully bootstrapped and regression tested on i686-linux.
Last week I've used earlier versions with an ARM compiler and seemed to
get small code size improvements on Crafty; it also fixes the remaining
issue with PR42502.  I'm also thinking of extending it further to do a
DCE of subreg stores which should help PR42575.


Bernd

Attachment: finalpiece.diff
Description: Text document