This is the mail archive of the gcc@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: egcs-1.1 status


On Sun, Aug 23, 1998 at 02:16:37AM +0200, Jeffrey A Law wrote:
> 
> 
>   In message <Pine.LNX.3.96.980822112054.3907C-100000@penguin.transmeta.com>you write:
>   > > I don't know.  But I can say for sure that using regparm is going to
>   > > cause problems on the x86.  They might get away with it for a while,
>   > > but in the end the compiler is going to silently generate incorrect
>   > > code.  It's not going to matter what compiler version they use, in
>   > > the end all of them are going to break.
>   > 
>   > Note that the kernel uses "regparm" only for certain functions, and I'm
>   > intentionally avoiding using it for anything where we use a function
>   > pointer, because that seems to be the major thing that triggers the
>   > problems.
> The problem is that reload can/will silently trash registers holding
> parameters while trying to satisfy reloads for later register loads.
> Note that reloads can be triggers in many non-obvious ways on the x86
> due to the way the machine description was written.
> 
> No code using regparm is safe.  Again, you might get away with it for
> a while, but in the end, it's going to generate incorrect code.  And
> (of course) the places where incorrect code is generated will vary
> from one version of the compiler to the next due to subtle differences
> in the generated code.
> 
> I strongly recommend against using regparm until such time as someone
> can rewrite reload to deal with machines with small register classes
> like the x86.

How about something like 

register void *arga asm("eax");
register void *argb asm("ebx");

void switch_to(void)
{
	/* use arga and argb */
}

Could this work?


> I would *love* for someone to start revamping reload since the benefits
> both in terms of efficiency of the generated code and the user interface
> issues with the "asm" which use too many regs are significant.

This is a real problem. I encountered it while porting some MMX code
from Visual C to gcc. The optimized inline assembler parts were using
lots of registers, and gcc/egcs complained about register shortage in
most cases. I ended up with having to move them into a separate assembler
file and take the cost of the "call".

-Andi


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