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:

> [the above might not have been as clear as it could have been]
> What you initially suggested was "to let users override GCC's internal
> memcpy/etc. functions" and i had assumed what you actually wanted was
> replacing not memcpy() itself, but the lower level code generated by
> the compiler. That was what the context suggested and that is how i
> interpret the below comment too -- and this is what i can't see a clean
> solution for.

i ment replacing memcpy itself, for the time being, because that one is
showing the problem. I mean (assuming an ideal compiler), i cannot see any
big conceptual difference - both a builtin and an external (inline)
function should result in similar RTL code emitted, no? Is there something
more subtle about built mempcy? Also i might be wrong about structure
copies, structure copies are using the builtin memcpy, right?

i did not really mean replacing some other builtin functions, obviously
__builtin_constant and others must have internal (version dependent GCC
data-structure) knowledge. The 'etc.' part ment 'memset()' and the other
memory-manipulation functions. Sorry if my sentence was confusing.

-- 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.795 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site