Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Jeffrey A Law <law at redhat dot com>]

  In message <20010109051946.N1120@devserv.devel.redhat.com>you write:
  > The major problem SPARC v9 has (there are other architectures with similar
  > problems) with this is that it is a 64bit architecture, thus WORD size is
  > 64bits, but there are still 32bit registers (float SFmode registers), so
  > there were problems in expressing e.g. store of high 32bits of 64bit %f8
  > register) etc. I believe this was the main reason why David Miller and
  > Richard Henderson (somebody else as well?) decided in 1998 that this needs
  > to change.
But this can also be solved by other means.

  1. You claim all registers are 64bits wide, including the FP registers.

  2. Obviously you cut the number of FP regs in half


The PA has 28 FP registers (%fr4 - %fr31).  They are 64bits wide.  However,
we can access either half of the 64bit quantity for storing and operating 
on single precision FP values.  For the PA32 port we expose the fact that
we can address the upper and lower halves of the FP registers.

Not surprisingly we ran into the same problem on the PA64 port as you've
run into on the sparc64 port.  However, we solved it in a completely 
different (and IMHO) much simpler, cleaner way.

Specifically we don't expose the fact that we can access the upper and
lower halves of FP registers independently.  ie, we expose 28 FP registers
that can hold either a 64bit value or a 32bit value.

The code is extremely clean and doesn't require any revamping of the
machine independent code because we don't have the SUBREG ambiguity to
deal with.

What did we lose with this scheme?  Nothing in reality.  Yes, we have fewer
places to stuff 32bit FP values (28regs instead of 56regs).  But the way the
FP pipeline works on the PA, it's actually very bad to access the upper and
lower halves of an FP register independently.

I'm not familiar enough with newer sparc architectures to know if this
scheme will work or not.  But I think it's worth consideration.

jeff