Re: strcmp is too heavy for its everyday usage...

[Denis Zaitsev <zzz@anda.ru>]

On Fri, Jan 09, 2004 at 12:12:31AM -0800, Richard Henderson wrote:
> On Fri, Jan 09, 2004 at 10:11:45AM +0500, Denis Zaitsev wrote:
> >     (r= a[0] - b[0]) &&
> >     (r= a[1] - b[1]) &&
> >     (r= a[2] - b[2]) &&
> >     (r= a[3] - b[3]);
> >     return r;
> > }
> > 
> > It's a typical inline code for compare 4-byte of mem.  When it is
> > used, say, in such a context
> > 
> >         s(a,b) ? A() : B();
> > 
> > GCC discards the value of r perfectly, leaving the only code needed
> > for compare bytes for eq/neq.  But GCC doesn't merge the 4 byte
> > comparing into single word comparing.  And, as I understand, it will
> > never do that, as it's not asked to.  Or this kind of optimization is
> > assumed ok for compiler, but just still unimplemented?
> 
> Certainly it's ok if it converts.
> 
> However, on most targets you'd have to know that a and b are aligned.
> Worse, even for targets like x86 that support unaligned loads you have
> to know for certain that neither a[3] nor b[3] could possibly segv
> when a[0] and b[0] won't.

Yes, and therefore this code is for memcmp, not for strcmp.  BTW, do I
understand right, that memcmp is free of that problem, as it has the
explicit length argument?  And this arg says implicitly, that the
access for the mem thru all this length is ok?