egcs-1.1 status

[Linus Torvalds]

On Sat, 22 Aug 1998, Jeffrey A Law wrote:
> 
>   > Hmm. Do you think explicitely coding it as an __asm__ would be sufficient
>   > as a workaround?
>
> 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 case where regparm is a noticeable win is things like "wrapper
functions", where we have a internal function that is not really meant to
be used directly, but that is exported through an inline (or more commonly
a define) that passes specific immediates as arguments to the function. It
often makes the function itself much nicer, but more importantly it makes
the calling sequence a lot more pleasant to look at. 

It also happens to be the best case for regparm - there is no register
pressure in actually setting up the argument registers. 

Jeff, you always seem to take compiler problems to be something really
negative. I would urge you and the other egcs developers to see this as
something _positive_ where you can actually look into the problem and try
to fix it, instead of throwing up your hands and saying "oh, gods, I can't
handle this, let's remove the feature".

There is no technical reason why you couldn't see a regparm function as
being a pattern with up to four input registers (three arguments and the
address) and one output register (return value - possibly two registers in
the case of long long) and a few clobbers. You already have to be able to
handle those kinds of patterns for inline assembly, so it's not as if this
is even any new requirement. 

Or are you going to remove inline assembly too? 

So your claim that it cannot ever be fixed for x86 is obviously bogus. Gcc
comes fairly close already, and instead of being so pessimistic just ask
people to help you fix the small problems egcs has now.

Yes, reload.c is horrible and hard to understand. I fully understand that
nobody feels really comfortable with trying to fixing any register
allocation problems. But "it cannot be fixed" is a loser approach, and if
egcs is really developed with that as the guideline then I can only
commiserate with you guys. 

In short, I've certainly tried to make it as easy as possible on the
compiler, but if "regparm" is one way of confusing the gcc register
allocator then you shouldn't see regparm as a problem, but as an
opportunity to find out what's wrong with reload.c.

I've already seem some people come up with really short example programs
of things that confuse egcs, and that should be the ideal reproducible
bug. And once it is easily reproducible it should be fixed instead of
saying "oh, somebody can reproduce a bug, let's get rid of the feature". 

		Linus