Generated libcalls

Generated libcalls

[Philipp Thomas]

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.
The reason is that gcc generated libcalls for those memcpy's exceeding the
limit. As there is no library available for kernel modules (memcpy calls
normally get inlined versions via linux/string.h), these can't be loaded.

While the modules in question did stupid things like passing 64 byte
structs by value, it's not exactly easy to find the spots where this
happens,

As IMO this is important for any freestanding target, I think we need something
like -ffreestanding, telling gcc to *not* generate such libcalls but instead
stop with an error in such cases.

But before I start looking at how to do this, I'd like to hear opinions on
this matter, as I could be on the wrong track of thinking (it's happened
before :).

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
SuSE GmbH, Deutschherrenstrasse 15-29, 90429 Nuremberg

"My brain functions well enough. I can breathe, walk, even post on news-
groups." - "I'm sorry, but we can't take any of those as evidence of a
functioning brain."              Ace Lightning, Lloyd Wood, talk.bizarre

Re: Generated libcalls

[Martin v. Loewis]

> As IMO this is important for any freestanding target, I think we
> need something like -ffreestanding, telling gcc to *not* generate
> such libcalls but instead stop with an error in such cases.

Based on our previous discussion, I'd say this looks like the right
thing. 

There is an alternative interface to achieve the same effect, do I
dare say #pragma? :-)

Martin

Re: Generated libcalls

[Philipp Thomas]

* Martin v. Loewis (martin@loewis.home.cs.tu-berlin.de) [20000301 01:02]:

> There is an alternative interface to achieve the same effect, do I
> dare say #pragma? :-)

Ahh, do I get this right that you're hinting at something like

#pragma libcall off

?
In that case I'd agree with that smiley ;-) But I'd still call for a
compiler switch because of the question where to put such a pragma. But
mostly because I'd rather avoid the inevitable discussion that would follow
the proposal to add a new #pragma ;->

The problem with this matter is, that, as Jan Hubicka pointed out to me,
it's rather hard to implement such a switch as at that point, a libcall is
just another function. I've never dealt with gcc on that level so I can't
make comments about the validity of that statement.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
SuSE GmbH, Deutschherrenstrasse 15-29, 90429 Nuremberg

Re: Generated libcalls

[Martin v. Loewis]

> But mostly because I'd rather avoid the inevitable discussion that
> would follow the proposal to add a new #pragma ;->

Indeed, so just ignore that proposal...

> The problem with this matter is, that, as Jan Hubicka pointed out to
> me, it's rather hard to implement such a switch as at that point, a
> libcall is just another function. I've never dealt with gcc on that
> level so I can't make comments about the validity of that statement.

Maybe I'm missing something, but... Currently, determination whether
to use memcpy or not is made with the line

  if (GET_CODE (size) == CONST_INT && MOVE_BY_PIECES_P (INTVAL (size), align))
    move_by_pieces (x, y, INTVAL (size), align);

I can't see the problem changing this to

  if (GET_CODE (size) == CONST_INT 
      && (flag_freestanding || MOVE_BY_PIECES_P (INTVAL (size), align)))
    move_by_pieces (x, y, INTVAL (size), align);

Of course, you'll have to catch a number of other cases as well
(e.g. clear-by-pieces), and you'll have to consider the case that
there's a copy where the size is not constant. However, I guess this
does not come up out of the compiler itself, only perhaps as a result
from calling __builtin_memcpy - which you shouldn't do in a
freestanding environment.

Please let me know if you do follow this approach.

Regards,
Martin

Re: Generated libcalls

[Richard Henderson]

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.


r~

Re: 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

Re: Generated libcalls

[Richard Henderson]

On Thu, Mar 09, 2000 at 05:00:59PM +0100, Jamie Lokier wrote:
> So I wonder, would GCC's struct copies generate inline calls to an
> inline memcpy function?

No.


r~