Re: I think I found a bug...

[Mark Grosberg <myg at tempest dot din dot net>]

On Wed, 1 Mar 2000, Geoff Keating wrote:

> > Date:   Wed, 1 Mar 2000 18:52:19 +0100
> > From: Ralf Baechle <ralf@uni-koblenz.de>
> 
> > > Any suggestions about what to do about it?
> > 
> > Glibc seems to attempt to try to inline things at any price.  So I'd
> 
> Actually, most of the cost is glibc trying to work out whether or not
> inlining is a good idea.

Well. Perhaps this logic could either be moved into the GCC compiler it's
self or done as an all/nothing optimization. My guess would be that if we
were to migrate this functionality into the compiler proper, it could
produce even better code on a wider array of architectures.

I don't know how I could get something like this started though.
 
> > suggest to be less agressive about that.  Calling a small subroutine on
> > MIPS is mostly expensive because the callee has to assume that alot of
> > temporary registers have been clobbered.  So my attempt for MIPS will

This is true for a lot of architectures though (varying degrees). But on
x86, we may wish to use the string instructions to some degree. On other
architectures it may depend on where data is. 

Only the machine description in GCC really knows for sure. So we could
define this as a new node type in GCC, no?

> > not be as extremly complex as the old routines.  For Intel the strategy
> > obviously needs to be different.
> 
> This probably won't help.  This is a compile-time problem, not an
> execute-time problem.  For the example given, I'd expect to see about
> six instructions generated, along the lines of
> 
   [ Insn's deleted ]

> since the strcpy operations are just storing the constant string "".
> This is actually a case where the inliners are helping.

Actually, nope. My posted test case had "*unknown*" being copied into the
string. I was using it for when uname() failed.
 
> > I assume the coredump bugs in egcs have been fixed in the meantime?
> 
> Hmmm.  Good point.

But this is a scary problem because a lot of systems will run out of swap
compiling that code and potentially dump core, panic, or kill GCC because
it is page faulting too much.

It seems scary that 6 lines of code can cause GCC's code generator to use
300+ MB of VM! (Even in the presence of macros).

How do you think we should attack this problem? 

L8r,
Mark G.