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 oneprovided 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 codethat first clears a structure only to immediately initialize it elementby element. Often the copy/clear could be eliminated partially or evencompletely). Sometimes it would make sense to merge several mem operationsinto one. etc. Right now i can't see a clean a way to provide alternativeimplementations 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 whilewaiting 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 thein/out macro definitions. While the string versions may not be themost used ones, it still isn't safe to silently pull the cld.Moving ins/outs etc further down inside #ifdef KERNEL would be a moreacceptable solution.

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/