This is the mail archive of the
mailing list for the GCC project.
Re: [PING] Re: SUBREGs and objects with holes
- From: Rask Ingemann Lambertsen <rask at sygehus dot dk>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 29 Oct 2006 13:20:07 +0100
- Subject: Re: [PING] Re: SUBREGs and objects with holes
- References: <200607191547.k6JFlr833934@makai.watson.ibm.com> <200608141758.k7EHwx828208@makai.watson.ibm.com> <E97DC0AE-2264-4B32-9E00-96FAB578F81B@apple.com> <200608142032.k7EKWX826228@makai.watson.ibm.com> <258CA653-FAAA-487C-81CF-A9C972432471@apple.com>
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
> >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