[PATCH] Optimize strcmp(ptr,ptr) and friends

[Michael Meissner]

On Mon, Jul 14, 2003 at 02:42:18PM -0600, Roger Sayle wrote:
> 
> The following patch should provide a interesting topic for discussion.
> It was recently suggested by a colleague that GCC could optimize many of
> the <string.h> builtins when both pointer arguments compared equal.  The
> patch below implements precisely this optimization for memcpy, mempcpy,
> memmove, strcpy, memcmp, strcmp and strncmp.
> 
> I believe the standards state that the resulting behaviour is undefined
> for all but memmove, memcmp, strcmp and strncmp, but it does no harm to
> provide "reasonable" interpretations for the rest.  The obvious question
> is whether those same standards require that memmove(ptr,ptr,n) or
> memcmp(ptr,ptr,n) must actually access the indicated memory, for
> read/write and read respectively.  For memcmp, for example, we'll already
> optimize away the "pure" call if the result isn't used, so there's some
> precedent.
> 
> Food for thought.
> 
> 
> The following patch has been tested on i686-pc-linux-gnu with a complete
> "make boostrap", all languages except treelang, and regression tested
> with a top-level "make -k check" with no new failures.  It relies on the
> fact that operand_equal_p returns false if either operand is a volatile
> pointer or otherwise side-effects.
> 
> Ok for mainline?

My question is whether it is really worth adding this optimization, since I
have a hard time imagining when it would be used in real code.  The only case I
can think of is if you have some convoluted macro usage that you do a string op
with an argument against a string literal, and the argument happens to be a
string literal also.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org