This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reload patch version 3


> > >> 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
> anyone?
>
> 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
registers.
The current problems with -mregparm on the i386 are examples of this. Another
one is the gcc.dg/clobbers.c test.

Bernd



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]