lkml.org 
[lkml]   [1999]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] string.h speedup, cld-2.3.30-C1

On Sun, 28 Nov 1999, Artur Skawina wrote:

> i'm saying a user-overriden builtin cannot be as efficient as one
> provided by the compiler [...]

why? Inline functions and macros are very effective as well. There is
nothing 'magic' about structure copies. GCC might as well assume what
memcpy does, and might optimize it away if it knows better. (eg. if all
structure fields are initialized shortly after copied.)

> [...] , 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.

no. The compiler can assume that our memcpy implementation is 'correct'
and has no side-effects, in that case it's free to eliminate dummy stores.

> 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.

(ok.)

-- mingo


-
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/

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