This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug string/18858] _HAVE_STRING_ARCH_xxx aren't defined for i386 nor x86_64
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 04 Mar 2016 17:26:08 +0000
- Subject: [Bug string/18858] _HAVE_STRING_ARCH_xxx aren't defined for i386 nor x86_64
- Auto-submitted: auto-generated
- References: <bug-18858-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18858
--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to joseph@codesourcery.com from comment #1)
> I think _HAVE_STRING_ARCH_mempcpy is expected to be defined only when
> mempcpy is an alternative entry point to memcpy, as otherwise using
> mempcpy will increase cache usage and so inlining the expansion in terms
> of memcpy is expected to be more efficient.
I think this needs to be backed up by some more performance measurements by
Intel.
The gcc developers have told us that this is a bad idea because of the register
usage. H.J. notes in bug 19759 that it uses a callee saved register.
The glibc developers note that it does give performance gains against the
microbenchmark.
Also impacted are the fortified __*_chk variant functions which all __*
versions of the real functions.
As I ask here:
https://www.sourceware.org/ml/libc-alpha/2016-03/msg00081.html
~~~
That is to say, should the change be made simply from
first principles that it's a good change, or do we need
a performance justification?
~~~
--
You are receiving this mail because:
You are on the CC list for the bug.