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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/