[PING] Re: SUBREGs and objects with holes

[David Edelsohn]

>>>>> Geoffrey Keating writes:

Geoff> I believe that the e500 case is simply unimplemented at this time in  
Geoff> these routines.  For example, subreg_offset_representable_p needs to  
Geoff> know to reject a request for the second SImode word of a DCmode value  
Geoff> that's being stored in integer registers, since that value doesn't  
Geoff> have an integer register number.

	subreg_offset_representable_p is not being called for the second
SImode word of a DCmode value, it is being called with the second DFmode
word of a DCmode value.

	Roger commented on IRC that your patch to the functions seems to
assume that the inner mode always is an integer mode.  If that were the
case, then your argument about dimensional analysis also would make sense.
However, your patch can change FPR word units into GPR word units.  Also,
the dimensional analysis referred to the assert, not the final result.
The result is dimensionally consistent, except that nregs_xmode changed
units.

	My message actually contained two proposed patches and we are
trying to include your input in the decision about which to apply.

	One patch maintains consistency in the computation of nregs_xmode
and nregs_ymode consistent.  If one uses

	nregs_xmode_unit_int * GET_MODE_NUNITS

instead of hard_regno_nregs, the other does as well.

	The other patch restricts the alternate computation of nregs_xmode
more severely.  Currently your algorithm tests

	nregs_xmode_unit != nregs_xmode_unit_int

It appears that your patch and reference to "holes" was concerned about
xmode and int_mode_for_mode (xmode) not being evenly divisible.  That
would be better captured by computing the modulus.  In other words, the
test is for partial xmode_units, not multiple xmode_units.

	Yet another possibility is to restrict the computation to the case
where one operand is INTEGRAL_MODE_P and the other is FLOAT_MODE_P.  This
also would capture the DCmode and SImode case and capture your comments
above.

	Again, the problem is that the function can be called with DCmode
and DFmode, not DCmode and SImode.  If the inner mode is SImode, then the
units already will match.  For DCmode and DFmode, the current algorithm
will find "holes" that do not exist.

Thanks, David