Ping: [Patch] aarch64: Thunderx specific memcpy and memmove

[Andrew Pinski]

On Thu, May 25, 2017 at 10:34 PM, Siddhesh Poyarekar
<siddhesh@gotplt.org> wrote:
> On Friday 26 May 2017 02:34 AM, Ramana Radhakrishnan wrote:
>> SVE in the ARM world is architectural and not micro-architectural in the context
>> of this discussion :) .
>
> Yes, I did not think of SVE as a micro-architecture detail.  I used SVE
> as an example to show that multiarch =/=> micro-architectures.
>
>> The difference in the ARM world compared to the x86 world is the number
>> of micro-architectures that target the same architectural baseline.
>> Pushing in a memcpy
>> for every single micro-architecture out there will make the library a
>> maintenance
>> nightmare !
>
> Nor am I arguing that micro-architectures ==> multiarch.  My comments
> have only been pointing out that the IFUNC cost for multiarch is here to
> stay and there will likely never be consensus to drop it given the
> innovations happening in the ARM server space.
>
>> And we also need to see some numbers which compare the relative performance
>> of the routines being put in compared to the generic memcpy otherwise things
>> will not improve.  Atleast something like this routine is X % better than the
>> generic memcpy.
>
> Yes, and I understand Steve had pointed out the benefits of his
> implementation in the original post.  If it turns out that the
> implementation is optimal for the general case, by all means merge it
> with the generic one but that's not a reason to drop multiarch.

One more comment about static linking.  In the server world nobody
static links any more.  It is not something people do at all.  It is
hard to do in a reasonable fashion any more due to how things like DNS
lookup in glibc.

Thanks,
Andrew

>
> Siddhesh