[i meant only my own words, of course]
> > 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?
Then i have no idea what you mean by "an external (inline)
function". How would you like to encode the required info?
Could you give an example? (i don't want to assume anything..)
[oh, i reread the above and noticed the "assuming an ideal compiler" [1]
part -- it's now a lot clearer ;). I was thinking more about "a
slightly improved gcc", and a short-to-medium term realistic solution.
But even in theory, could you write a memcpy() function using C
plus existing compiler extensions (more or less, ie w/o exposing too
much compiler internals) that's not less efficient than a builtin
one? [what i think effectively comes down to the situation i described
in the previous msg, but wouldn't mind being proven wrong :)]
[1] an ideal compiler doesn't need any builtins, obviously.
> 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.
oh, no, in that case it's all my fault. it's just that i didn't want to
believe you were suggesting something that didn't seem to really solve
the problem the best way possible. Sorry.
-
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/