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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org, Andrew Pinski <pinskia at gmail dot com>
- Date: Thu, 4 Jun 2015 10:43:27 +0200
- Subject: Re: Gcc builtin review: memcpy, mempcpy, memmove.
- Authentication-results: sourceware.org; auth=none
- References: <20150525101505 dot GA11233 at domone> <alpine dot DEB dot 2 dot 10 dot 1505281627540 dot 16930 at digraph dot polyomino dot org dot uk> <55674520 dot 5030002 at redhat dot com>
On Thu, May 28, 2015 at 10:41:04AM -0600, Jeff Law wrote:
> On 05/28/2015 10:36 AM, Joseph Myers wrote:
> >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.
> Agreed. Trying to address all this stuff in glibc is wrong. Each
> issue should be evaluated and a determination made individually
> whether the issue should be addressed in gcc or glibc.
>
>
> Jeff
Ok, I will crosspost issues that needs to be addressed. The main two
problems are that lot of special cases should be handled as ordinary
code, not trying to add extra pass every time you notice that sometimes
you could expand foo into bar and baz. Then there are implementation
details and that correct decision depends on these. For optimizations
you need to know how fast are different libc functions which is easier
checkable inside libc than trying to sync that information in gcc.