Generated libcalls

[Jamie Lokier]

Richard Henderson wrote:
> On Tue, Feb 29, 2000 at 11:17:52PM +0100, Philipp Thomas wrote:
> > Jan's recent addition of stringop optimization also lowered the limit up to
> > which gcc will inline memcpy calls. This broke some Linux kernel modules.
> [...]
> > As IMO this is important for any freestanding target...
> 
> No, it's not at all important.  The x86 linux kernel should provide
> memcpy as a symbol just like the alpha linux kernel does.

They decided on a different solution: don't use struct copies.
You are supposed to use their struct_cpy() macro instead.

The irony is that their struct_cpy() simply calls memcpy.
memcpy() is inlined in some cases on Linux x86: it is a macro which uses
__builtin_constant_p() to decide what to call.

Even when they inline the "rep; movsl" sequence, that code is better
than GCC's builtin.  That's because GCC's builtin emits a "cld"
instruction, which isn't required in the Linux kernel.

Nowadays __builtin_constant_p() works in inline functions, so it would
be possible to make Linux' memcpy an inline function.

So I wonder, would GCC's struct copies generate inline calls to an
inline memcpy function?

It's difficult to tell.  I just tried some struct copying with GCC
2.95.1, and it always generated its own built in string copy using "cld;
rep; movsl".  Even with -fno-builtin (that shouldn't stop it but I
thought I'd try).

-- Jamie