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

[Denis Zaitsev <zzz@anda.ru>]

On Thu, Jan 08, 2004 at 10:30:04AM +0100, Andreas Schwab wrote:
> Denis Zaitsev <zzz@anda.ru> writes:
> 
> > On Wed, Jan 07, 2004 at 05:13:11PM -0800, Roland McGrath wrote:
> >
> >> The optimized string functions already do word comparisons when
> >> that is possible and advantageous.  The comparisons to extract
> >> the ordering vs just equality/nonequality are only on the first
> >> nonmatching byte.
> >
> > But it's an overhead anyway.
> 
> Rather neglectable, IMHO.

Nearly agreed.

> > Then, it's bad enough for the inlining.
> 
> If it's inlined then the compiler should be smart enough to discard
> the unneded bits.  If not, and the difference is measurable, then
> the compiler should be fixed.

GCC is smart enough.  It doesn't do the job thru the best possible
way, but this should and (important!) can really be fixed.  So,
generally I agree again.  But suppose such an example:

extern inline
s(const unsigned char *a, const unsigned char *b)
{
    int r;
    (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?