This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 6/6] Compile sched_getaffinity.c with -fno-builtin-memset
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 14 Aug 2015 16:02:50 +0000
- Subject: Re: [PATCH 6/6] Compile sched_getaffinity.c with -fno-builtin-memset
- Authentication-results: sourceware.org; auth=none
- References: <20150814121907 dot GF28610 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1508141519370 dot 16651 at digraph dot polyomino dot org dot uk> <CAMe9rOrzffv07T31oDX9oVcTpxJ=_kiFNgqcKdgoYbCzvRnEuw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1508141534210 dot 16651 at digraph dot polyomino dot org dot uk> <CAMe9rOo_qfVjN3Wfj9FpPTD_p+EQ-iFDeVA6hJiBYzex93ijOg at mail dot gmail dot com>
On Fri, 14 Aug 2015, H.J. Lu wrote:
> > point to the GOT as it would for a call through the PLT. I don't know
> > whether this gets optimized for built-in function calls using
> > libc_hidden_builtin_proto, but if it doesn't, that seems like a missed
> > optimization that should be addressed in the compiler not in glibc.
> >
>
> It is hard to say it is a GCC issue when we are kind of doing this behind
> the back of GCC unless there is a way to tell GCC that the libcall of
> a builtin function is hidden.
We're declaring (essentially, though a load of macros):
extern __typeof (memset) memset __asm__ ("__GI_memset") __attribute__ ((visibility ("hidden")));
GCC is using the __asm__ information to compile calls to __builtin_memset
to use the assembler name __GI_memset - that is, in that regard our
declaration is being taken as applying to the libcall. If it's not also
using the visibility information to know that those are calls within the
library and don't need to set up %ebx, that's a clear inconsistency; all
pieces of information from an explicit declaration of a built-in function
should be treated the same unless there is a clear reason not to do so.
--
Joseph S. Myers
joseph@codesourcery.com