This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: strcmp is too heavy for its everyday usage...
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?