Re: [PATCH] Fix optimization/10904

[Richard Henderson <rth at redhat dot com>]

On Sat, Jun 07, 2003 at 10:56:17PM +0200, Eric Botcazou wrote:
> Is this the right approach? I'm a bit worried because I'm afraid that reload 
> might screw up everything afterwards.

I think there is a good chance that reload will screw up after.

I think we need to re-structure the FP register classes on Sparc.
Something like

#define REG_CLASS_CONTENTS						\
  {{0x00000000, 0x00000000, 0x00000000, 0x00},  /* NO_REGS */           \
   {0x00000000, 0x00000000, 0x00000000, 0x0f},  /* FPCC_REGS */         \
   {0x0000ffff, 0x00000000, 0x00000000, 0x00},  /* I64_REGS */          \
   {0xffffffff, 0x00000000, 0x00000000, 0x20},  /* GENERAL_REGS */      \
   {0x00000000, 0x11111111, 0x11111111, 0x00},  /* FP_Q_REGS */         \
   {0x00000000, 0x55555555, 0x55555555, 0x00},  /* FP_D_REGS */         \
   {0x00000000, 0xffffffff, 0x00000000, 0x00},  /* FP_S_REGS */         \
   {0xffffffff, 0xffffffff, 0xffffffff, 0x20},  /* GENERAL_OR_FP_REGS */ \
   {0xffffffff, 0xffffffff, 0xffffffff, 0x3f}}  /* ALL_REGS */

When !TARGET_V9, the high registers will simply be marked fixed,
and so they won't be used or usable.

I think we can just map 'f' -> FP_S_REGS and 'e' -> FP_D_REGS
and get good backward compatibility with existing assembly code;
that just leaves choosing a new letter for FP_Q_REGS.  Not that
hardware for TFmode hard-fp exists...

I tried prototyping this right quick, but didn't get everything
right, and it crashes.  Attached, if you're interested in using
it as a starting point, or seeing what not to do.  ;-)

Oh, something else that might be worthwhile, in terms of speeding
up the compiler a little bit -- gid rid of the unused 16 registers
between 64 and 95.  Just because the hard register name is %f38 is
no reason that the internal register number has to be FP_BASE + 38.
That'd be for a separate cleanup, I'd think...


r~

Attachment: z
Description: Text document