Re: [9fans] plan or side effect

[David Gordon Hogan <dhog@plan9.bell-labs.com>]

> No, in general GCC does not have such knowledge.  
> 
> If it is able to inline the function, then of course it can do the
> optimization, but an inlined function isn't a function call at all, so
> that's really a different case.
> 
> Also, GCC has some builtin functions; it knows the behavior of those.
> But not (in general) library functions.

It certainly knows about strcpy() and memmove() (or
whatever they're #defined to in the headers).  So for
instance,

	strcpy(s, "xyzzy");

will get replaced with a bunch of instructions to store the
appropriate constant values in s.

I'm just reporting, I don't think it's a particularly good thing.
Like, do we really need that extra .1% speed improvement,
at the expense of code size, compile speed, and transparent
behaviour?

When I say .1%, I'm just pulling a number out of the air.
Clearly, if your program is composed entirely out of
strcpy's of constants, the improvement could be much
larger(!).  But, I claim that this is a pathological case,
and the time wasted on such `improvements' is generally
better spent elsewhere (like, maybe, some day, someone
will simplify the morass of #ifdefs that GCC and Binutils
are afflicted with...).