This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ping: [Patch] aarch64: Thunderx specific memcpy and memmove
On Wednesday 10 May 2017 03:15 AM, Steve Ellcey wrote:
> That sounds reasonable to me. Here is a patch that contains a separate
> memcpy_thunderx implementation. I still have some (minor) changes to
> the generic memcpy.S file. One change is to use macros for the
> function names so that the generic multiarch memcpy can include the
> standard non-multiarch version. The other is to change a couple of
> internal labels to external labels. This change isn't absolutely
> necessary but it is helpful in the thunderx memcpy where the branches
> are slightly different and I would like to keep the thunderx memcpy and
> the generic memcpy as similar as possible so that when a change happens
> in one or the other it is easy to compare the two versions. I don't
> believe using different label types affects the generated code at all
> and personally, I find named labels easier to read than the internal
> numbered labels. Being able to compare the two memcpy's is also why I
> kept the THUNDERX ifdef in memcpy_thunderx.S even though it is always
> defined there, so that the intended differences are explicit when
> comparing the two versions of memcpy.
>
> Tested on the top-of-tree sources with no regressions.
The patch looks fine. Please coordinate with Szabolcs and Wilco on the
way forward. You could either commit now and let Wilco rebase on top of
your changes or wait till he is done with his analysis and then figure
out the next step.
Siddhesh
PS: You don't really need the USE_THUNDERX macros in your memcpy
anymore, but it's not a big deal if that is what you prefer to keep
track of generic memcpy changes since you own that code.