This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: more m68k breakage on m68k-linux
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/