This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/4] Tune and tweak memmove/wordcopy code for Powerpc
On Mon, Mar 19, 2012 at 4:16 PM, David Miller <davem@davemloft.net> wrote:
> From: Will Schmidt <will_schmidt@vnet.ibm.com>
> Date: Mon, 19 Mar 2012 16:01:30 -0500
>
>> The "Call memcpy when appropriate" optimization (4/4) could apply to
>> other architectures generically; but I can not make any claims to
>> how much improvement (if any) it provides for those archs.
>
> One problem with this is that currently internal calls to memcpy
> inside of libc won't use the IFUNC variant.
I believe this isn't a problem for us at the moment since we use
--with-cpu to hardwire the internal calls based on arch. We don't
have multi-lib setup for Power yet, but it's on our short list.
> Right now __GI_memcpy ends up being set to the least-optimized variant
> a sysdep provides. ÂThe same thing happens for memset.
>
> This is done primarily because it's hard to ensure that we won't make
> a memcpy or memset call before the dynamic linker is done booting up
> and this is able to run the PLT resolver properly. ÂI really think
> we can and should fix this though.
Yes, for instance in the power7 case, if memmove is to make an
internal call to memcpy then memcpy should be resolved by the linker
with a direct branch to the power7 memcpy. The memcpy symbol variants
that are resolved by IFUNC are labeled by submachine so the power7
memmove should be able to branch to the power7 memcpy directly.
>
> I've seen the unoptimized memset and memcpy show up in the profiles
> under certain workloads, so it's not just a "would be nice" kind of
> issue.
> On another note, do you guys plan on converting all of this chip
> specific powerpc code over to multiarch so you can share those
> problems with the rest of us? Â:-)
Yes. Hopefully relatively soon.
Ryan