[lkml]   [1999]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] string.h speedup, cld-2.3.30-C1
Ingo Molnar wrote:
> > third, gcc unconditionally generating clds everywhere is a compiler
> > issue, which should be fixed in compiler land. something like
> > -mno-implicit-clds. (working around the problem by disabling gcc
> > optimizations isn't an optimal solution)
> i believe the 'ideal' solution would be to let users override GCC's
> internal memcpy/etc. functions. Right now it's about cld's. But maybe in
> the (not so far) future we want to use SIMD instructions to do memory
> copies, etc.

i'm saying a user-overriden builtin cannot be as efficient as one
provided by the compiler, simply because the compiler knows more,
and can use that knowledge in ways that are not possible with "normal"
inlined code. Think dummy store elimination (eg: there's a lot of code
that first clears a structure only to immediately initialize it element
by element. Often the copy/clear could be eliminated partially or even
completely). Sometimes it would make sense to merge several mem operations
into one. etc. Right now i can't see a clean a way to provide alternative
implementations of the builtins that would not be very compiler (version)
specific and not loose any useful info (ie prevent optimizations).
Being able to override builtins would still be useful, eg while
waiting for the compiler to catch up.

> > these changes are visible to userland; either your previous
> > /cld-ifdef-KERNEL approach/ or simply /#ifdef-KERNEL the whole header/
> > would probably be safer.
> ok, agreed. Although these days anything that is using kernel headers is
> more or less considered buggy. glibc 2.0+ has it's own string.h.

it's not only about string.h; asm/io.h was/is often used to get the
in/out macro definitions. While the string versions may not be the
most used ones, it still isn't safe to silently pull the cld.
Moving ins/outs etc further down inside #ifdef KERNEL would be a more
acceptable solution.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.053 / U:13.324 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site