This is the mail archive of the
mailing list for the GCC project.
Re: Reload patch version 3
- To: Geoff Keating <geoffk at ozemail dot com dot au>
- Subject: Re: Reload patch version 3
- From: Bernd Schmidt <crux at pool dot informatik dot rwth-aachen dot de>
- Date: Tue, 1 Sep 1998 15:56:45 +0200 (MET DST)
- cc: Franz dot Sirl-kernel at lauterbach dot com, egcs-patches at cygnus dot com
> > >> Additionally your patch seems to fix Geoff's pet bug ;-) asm("" : : :
> > >> "cc"), which now compiles just fine (also part of the configure tests of
> > >> glibc-2.0.95).
> > >
> > >Could you explain quickly why this wouldn't work before?
> > I think (!) it has something to do with the multiple condition code
> > registers (cr0-cr7, 4 bit each, combined into one 32bit reg, dunno if cc
> > means cr0 or the whole 32bit reg) available on PPC.
> It's caused by having a register which is alone in its class, and
> naming that register in the asm statement, and then having the RTL
> trying to allocate a register from the class.
> CR0_REGS contains only the register 'cr0' (also known as 'cc'). It's
> not specific to that class, there are other classes that do the same
> thing on ppc like LINK_REGS and COUNT_REGS.
And since some of the patterns in rs6000.md use things like
(clobber (match_scratch:CC "=X,x"))
and thus leave the job of allocating CR0 to the register allocator, it
can't at the same time be used explicitly. I understand the failure now.
Couldn't you write 'asm ("" : "=&x" : )' instead to show the compiler that
CR0 is clobbered? This should have the same effect.
> I think the reason for the restriction is that reload doesn't reliably
> allocate pseudos to a register if the register is also named
> explicitly somewhere else. I don't have an example of this; does
> Some ports work around this by defining the macro
> 'SMALL_REGISTER_CLASSES', but that reduces the quality of the
> generated code, and it's not worth it to fix this small bug.
It doesn't actually fix the bug; instead it creates new ones. Once you
define SMALL_REGISTER_CLASSES reload no longer guarantees that the
reload registers it chooses don't conflict with the explicitly used hard
regs - it just puts these at the end of its list of potential reload
The current problems with -mregparm on the i386 are examples of this. Another
one is the gcc.dg/clobbers.c test.