This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug string/18858] _HAVE_STRING_ARCH_xxx aren't defined for i386 nor x86_64


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]