This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Gcc builtin review: memcpy, mempcpy, memmove.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: <libc-alpha at sourceware dot org>, Andrew Pinski <pinskia at gmail dot com>
- Date: Thu, 28 May 2015 16:36:51 +0000
- Subject: Re: Gcc builtin review: memcpy, mempcpy, memmove.
- Authentication-results: sourceware.org; auth=none
- References: <20150525101505 dot GA11233 at domone>
On Mon, 25 May 2015, Ondřej Bílka wrote:
> Andrew as I promised review and what you would need to fix for x64 gcc
> and remove ugly gcc hacks and replace them with nice headers :-)
>
> I will take a functions in order from string.h and comment about
> these.
Reviews of optimization issues with GCC built-in functions belong
primarily in the GCC context, not glibc at all. That is, file one report
in GCC Bugzilla for each issue you find that isn't already reported there
(making sure to give the usual details of GCC version, target, compilation
options etc.). File a meta-bug in GCC Bugzilla depending on all those
bugs (and any pre-existing bugs for issues you found that you didn't
report because they were already reported there). Then just send a
summary to the libc-alpha and gcc lists pointing to that meta-bug.
This applies to most of your reviews of GCC built-in functions - send the
reports where they belong, and any temporary implementations of
optimizations in glibc headers need comments pointing to the GCC bug
reports which point back to those comments. Only where an optimization
involves calling glibc-specific functions are compiler optimizations more
troublesome (and even there, GCC knows when it's compiling for a glibc
target and knows the minimum glibc version supported on the target, so
it's entirely reasonable to agree that e.g. __rawmemchr will remain
available as a public glibc ABI so that GCC can generate code calling it
on glibc targets unless told not to because e.g. generating kernel code).
> Then you have problem that optimum also depends on profile feedback. If
Which is clearly better handled in the GCC context (GCC has the
infrastructure to handle profile feedback data from training runs of the
program) than in headers.
--
Joseph S. Myers
joseph@codesourcery.com