From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] plan or side effect From: David Gordon Hogan MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 28 Feb 2002 12:41:59 -0500 Topicbox-Message-UUID: 5c4306d2-eaca-11e9-9e20-41e7f4b1d025 > 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...).