Re: [PING] Re: SUBREGs and objects with holes

[Rask Ingemann Lambertsen <rask at sygehus dot dk>]

On Mon, Aug 14, 2006 at 02:40:27PM -0700, Geoffrey Keating wrote:
> 
> On 14/08/2006, at 1:32 PM, David Edelsohn wrote:

> >  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.
> 
> No, my patch really was concerned with the case where a value takes a  
> different number of registers in its mode than it would have taken in  
> an integer mode.  Divisibility seems like an arbitrary way of  
> 'detecting x86', see my first comment at the top.

   The code essentially expects

	xmode_unit_int = int_mode_for_mode (xmode_unit);
	nregs_xmode_unit_int = hard_regno_nregs[xregno][xmode_unit_int];

to put a meaningful value in nregs_xmode_unit_int, but IMHO, it is bogus.
If nothing else, it needs to be guarded by HARD_REGNO_MODE_OK (xregno,
xmode_unit_int). But note that int_mode_for_mode (XFmode) may well return
BLKmode if no 96-bit integer mode exists. The code checks for this:

      if (xmode_unit_int == BLKmode)
        /* It's probably bad to be here; a port should have an integer mode
           that's the same size as anything of which it takes a SUBREG.  */
        xmode_unit_int = xmode_unit;

   I could use some clarification here. Why, on a 16-bit CPU, would you need
a 96-bit integer mode for
(subreg:HI (reg:XF 0) 0)
(subreg:HI (reg:XF 0) 2)
...
(subreg:HI (reg:XF 0) 8)
?

   I don't understand why the code looks at int_mode_for_mode() in the first
place. In particular, is there any chance that GET_MODE_SIZE
(int_mode_for_mode (xmode_unit)) != GET_MODE_SIZE (xmode_unit)?

> Ideally, this test would not be necessary, and the code could use  
> this code path all the time.  I think that would make the code  
> cleaner.  Obviously it would require careful thought.

   I think the real difficulty here is that there is no target specific
macro which defines the number of bytes a register holds as part of a value
of a given mode. Something like

	HARD_REGNO_NBYTES (regno, xregno, xmode)

where regno is the register we want to know the size of, xregno is the inner
register of a subreg and xmode is the inner mode of a subreg.

> I did not intend the comment to be an exhaustive list of the cases  
> that can go wrong, merely a single example to show the general problem.

   I think this is tricky to get right in general with the current support
from the backends. You might have HARD_REGNO_NREGS (0, XFmode) return 6 and
a reg_raw_mode[] array with HImode, CCmode, QImode, QImode, CCmode, HImode
and then someone wants (subreg:QI (reg:XF 0) 4). I don't see how you can
calculate the regno offset, even if it is well defined, in this case,
without something like HARD_REGNO_NBYTES().

-- 
Rask Ingemann Lambertsen