more m68k breakage on m68k-linux

[Bernardo Innocenti]

Gunther Nikl wrote:
> Hello Bernado!
> 
> On Mon, Mar 08, 2004 at 10:38:03PM +0100, Bernardo Innocenti wrote:
> 
>>Gunther Nikl wrote:
>>
>>>On Sun, Mar 07, 2004 at 04:05:50PM +0100, Bernardo Innocenti wrote:
>>>
>>>
>>>>Roman Zippel wrote:
>>>>
>>>>
>>>>>Does your patch look very different from the one below?
>>>>>That's the one I'm testing for m68k-linux right now.
>>>>
>>>>It's similar, but I didn't notice REGNO_REG_CLASS also needed fiddling,
>>>>so your patch is superior.
>>>
>>> Why are so many changes required to fix the breakage caused by adding
>>> argptr?
>>
>>Because the target configuration infrastructure used by GCC is a hell
>>ofpreprocessor macros with very weak consistency checking? :-)



> 
>   No, that wasn't my real question ;-) I thought that just adding argptr
>   to FIXED_REGISTERS+CALL_USED_REGISTERS would be enough. But the patch
>   adds REG_ALLOC_ORDER and modifies REG_CLASS_CONTENTS+REGNO_REG_CLASS.

Well, the REGNO_REG_CLASS is needed for correctness in case the middle-end
invokes it on the argument pointer.  I dunno if it really does, but better
safe than sorry.  The divide-by-8 trick doesn't work any more, so Roman
converted the clever formula to a table.

For other's reference:

`REGNO_REG_CLASS (REGNO)'
     A C expression whose value is a register class containing hard
     register REGNO.  In general there is more than one such class;
     choose a class which is "minimal", meaning that no smaller class
     also contains the register.

Roman's changes:

 -#define REGNO_REG_CLASS(REGNO) (((REGNO)>>3)+1)
 +extern char regno_reg_class[];
 +#define REGNO_REG_CLASS(REGNO) ((enum reg_class)regno_reg_class[(REGNO)])

 ...

 +char regno_reg_class[] =
 +{
 +  DATA_REGS, DATA_REGS, DATA_REGS, DATA_REGS,
 +  DATA_REGS, DATA_REGS, DATA_REGS, DATA_REGS,
 +  ADDR_REGS, ADDR_REGS, ADDR_REGS, ADDR_REGS,
 +  ADDR_REGS, ADDR_REGS, ADDR_REGS, ADDR_REGS,
 +  FP_REGS, FP_REGS, FP_REGS, FP_REGS,
 +  FP_REGS, FP_REGS, FP_REGS, FP_REGS,
 +  ADDR_REGS
 +};


>   I checked the documenation but it wasn't that helpful regarding
>   REG_ALLOC_ORDER. Why is that one now needed?

I'm puzzled too... I think Roman wanted to make sure argptr wasn't
being ever allocated, but this is easly accomplished by setting it
to 1 in FIXED_REGISTERS.

All code paths for targets that don't define REG_ALLOC_ORDER look
safe to me even for the argument pointer fake register.


>   BTW, the patch should be posted quickly because  according to
>   http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00513.html 3.4.0 is
>   scheduled for its final code freeze soon. IMHO, this patch must be
>   in 3.4.0.

Yeah.  Sorry for the delay, I'll see if I can work on it later this
week.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/