Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Zhangxuelei (Derek)]

Hi Florian,

> Has there been a reply to this question?  
> If yes, it didn't make it to the list.  Thanks.

Yes, I replied 2 days ago as follow.

>> What is the current status of Huawei's copyright assignment with the 
>> FSF?

> Yes, we have already signed the copyright assignment with FSF at 09 
> Oct. 2019. My CLA ID is 1436346.

Cheers,
Xuelei

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Carlos O'Donell]

On 10/26/19 9:22 AM, Zhangxuelei (Derek) wrote:
> Hi Florian,
> 
>> Has there been a reply to this question?  
>> If yes, it didn't make it to the list.  Thanks.
> 
> Yes, I replied 2 days ago as follow.
> 
>>> What is the current status of Huawei's copyright assignment with the 
>>> FSF?
> 
>> Yes, we have already signed the copyright assignment with FSF at 09 
>> Oct. 2019. My CLA ID is 1436346.

This hasn't yet appeared in the global list of copyright assignments.

I have sent the FSF Records clerk a question to verify and get the list
updated.

Thank you for your patience.

-- 
Cheers,
Carlos.

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Zhangxuelei (Derek)]

Hi Carlos,

> At present Huawei does not have an employer disclaimer.
>
> If any of this work can be claimed by Huawei then it cannot be 
> integrated into glibc.
>
> The FSF is following up with Huawei about this. There was some 
> confusion over exactly what kind of disclaimer, personal vs.
> employer, was being requested.
>
> My sincerest apologies for the delay as we sort this out.

We have receveid and replied the mail from @Craig, it seems we need request corporate assignment.

I will sync our results ASAP after @Craig replied.

Thanks for your attention and reminder.

-
Regards
Xuelei

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Carlos O'Donell]

On 10/28/19 11:22 PM, Zhangxuelei (Derek) wrote:
> Hi Carlos,
> 
>> At present Huawei does not have an employer disclaimer.
>>
>> If any of this work can be claimed by Huawei then it cannot be 
>> integrated into glibc.
>>
>> The FSF is following up with Huawei about this. There was some 
>> confusion over exactly what kind of disclaimer, personal vs.
>> employer, was being requested.
>>
>> My sincerest apologies for the delay as we sort this out.
> 
> We have receveid and replied the mail from @Craig, it seems we need request corporate assignment.
> 
> I will sync our results ASAP after @Craig replied.
> 
> Thanks for your attention and reminder.

Thank you very much for the prompt reply to the FSF!

-- 
Cheers,
Carlos.

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Yikun Jiang]

Hi, Carlos or someone can reply, : ) Sorry to bother you guys in here.

And @Craig mentioned the corporate copyright assignment from
copyright-clerk@fsf.org, but no more detail information in follow up.

Looks like we have two choice:
a. employer disclaimer + individual assignment
b. corporate assignment

We are employees of Huawei, and we have achieved the company's
approval to contribute the code in GNU Glibc.

and we have already signed the individual assignment with FSF. (Yikun
Jiang(1435635), Xuelei Zhang(1436346)).

Could you tell us which the copyright assignment should we use? What
should we do for the next step?

Regards,
Yikun

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Carlos O'Donell]

On 10/30/19 2:42 AM, Yikun Jiang wrote:
> Hi, Carlos or someone can reply, : ) Sorry to bother you guys in here.
> 
> And @Craig mentioned the corporate copyright assignment from
> copyright-clerk@fsf.org, but no more detail information in follow up.
> 
> Looks like we have two choice:
> a. employer disclaimer + individual assignment
> b. corporate assignment
> 
> We are employees of Huawei, and we have achieved the company's
> approval to contribute the code in GNU Glibc.
> 
> and we have already signed the individual assignment with FSF. (Yikun
> Jiang(1435635), Xuelei Zhang(1436346)).

Having individual assignments with the FSF is very good.

> Could you tell us which the copyright assignment should we use? What
> should we do for the next step?

You have a choice. The choice you choose depends on what Huawei,
as a company, wishes to do.

a. Employer disclaimer
- The employer signs an agreement with the FSF saying they disclaim
  the ownership of the work you are doing on glibc.

b. corporate assignment
- The employer signs an assignment to assign copyright of employee
  work to the FSF for work done on glibc.

They are legally distinct processes, and this decision should be
taken, usually, to Huawei's legal representative to decide which
is best for the company.

You should ask the FSF for copies of both of these documents that
need to be signed by your employer, such that you can take them
into any kind of meeting you will have internally.

Next steps:
- Get documents from the FSF.
- Have an internal meeting at Huawei with company legal representatives
  and explain the choices, and get support for one.
- Work with the FSF to complete one of the two documents.

-- 
Cheers,
Carlos.

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Zhangxuelei (Derek)]

Hi Wilco, sorry for the delay in replying because we tested lot after modifing memmove.

> In order to select the right memmove implementation,
> multiarch/memmove.c needs similar changes as multiarch/memcpy.c.

That's true, we missed this patch and will submit it next patch.

> Also since the memmove entry sequence does both check for medium
> and large cases, the full overlap check should be done in both.
> Currently only sizes 96-512 benefit, not the move_long case:

Yes, we will add full overlap check in move_long case next patch.

And what confusing us now is that, we removed dst_unaligned code in memcpy according to the previous comments, which did not affect performance after testing in memcpy cases. But in the case when uses memmove function and enters the memcpy part, unaligned cases is significantly slower than aligned case according to the results of the first half part of memmove-walk as shown in the bottom. So do you think we should still remove dst_unaligned code? 

We analyse the reason is of more judgement in the begin of memmove and may weak processor ability to handle this case, and so dst_unaligned make difference.

> Well it looks the dst_unaligned code (which deals with a specific
> issue on ThunderX2) ...

I remember you memtioned the specific issue on ThunderX2 before, could you tell us more about it?

Function: memmove
Variant: walk
                    __memmove_thunderx	__memmove_thunderx2	__memmove_falkor	__memmove_kunpeng2	__memmove_generic
========================================================================================================================
      length=128:        33.99 (-73.69%)	       18.65 (  4.67%)	       17.75 (  9.29%)	       19.21 (  1.80%)	       19.57	
      length=129:        35.41 (  2.08%)	       37.43 ( -3.51%)	       35.87 (  0.79%)	       34.71 (  4.01%)	       36.16	
      length=256:        45.55 (-37.95%)	       32.61 (  1.23%)	       35.59 ( -7.79%)	       32.95 (  0.20%)	       33.02	
      length=257:        66.36 (  4.20%)	       69.50 ( -0.33%)	       68.03 (  1.80%)	       68.53 (  1.08%)	       69.27	
      length=512:        82.77 (-34.10%)	       65.67 ( -6.41%)	       65.61 ( -6.30%)	       60.13 (  2.57%)	       61.72	
      length=513:       146.19 (  3.90%)	      132.98 ( 12.59%)	      132.28 ( 13.05%)	      151.50 (  0.41%)	      152.12	
     length=1024:       155.75 (-26.13%)	      142.74 (-15.60%)	      126.97 ( -2.83%)	      121.58 (  1.53%)	      123.48	
     length=1025:       289.15 (  4.72%)	      318.71 ( -5.02%)	      262.97 ( 13.35%)	      307.00 ( -1.16%)	      303.48	
     length=2048:       298.85 (-22.16%)	      233.98 (  4.35%)	      249.71 ( -2.08%)	      245.37 ( -0.30%)	      244.63	
     length=2049:       409.46 ( 14.62%)	      399.08 ( 16.78%)	      508.64 ( -6.07%)	      465.79 (  2.87%)	      479.54	
     length=4096:       543.10 (-11.30%)	      445.35 (  8.73%)	      491.40 ( -0.71%)	      435.61 ( 10.73%)	      487.95	
     length=4097:       680.95 ( 18.96%)	      593.99 ( 29.31%)	      990.52 (-17.89%)	      882.91 ( -5.08%)	      840.23	
     length=8192:      1047.46 ( -8.01%)	      867.03 ( 10.59%)	      977.80 ( -0.83%)	      850.57 ( 12.29%)	      969.74	
     length=8193:      1224.46 ( 21.97%)	      979.34 ( 37.59%)	     1981.71 (-26.29%)	     1714.96 ( -9.29%)	     1569.12	
    length=16384:      2055.73 ( -5.42%)	     1701.01 ( 12.77%)	     1944.38 (  0.29%)	     1683.51 ( 13.67%)	     1950.11	
    length=16385:      2314.62 ( 23.38%)	     1774.44 ( 41.26%)	     3967.45 (-31.34%)	     3385.52 (-12.07%)	     3020.82	
    length=32768:      5153.99 (-32.25%)	     3426.50 ( 12.08%)	     3875.16 (  0.56%)	     3338.91 ( 14.32%)	     3897.16	
    length=32769:      5343.41 (  9.64%)	     3375.50 ( 42.92%)	     7925.06 (-34.01%)	     6716.28 (-13.57%)	     5913.72	
    length=65536:     10361.70 (-35.90%)	     6768.32 ( 11.23%)	     7759.75 ( -1.78%)	     6658.73 ( 12.66%)	     7624.32	
    length=65537:     10284.00 ( 12.00%)	     6528.85 ( 44.13%)	    15844.40 (-35.58%)	    13437.90 (-14.98%)	    11686.80	
   length=131072:     20539.30 (-34.71%)	    13672.50 ( 10.33%)	    15567.10 ( -2.10%)	    13325.60 ( 12.60%)	    15247.50	
   length=131073:     20868.20 ( 10.97%)	    12807.80 ( 45.36%)	    31605.90 (-34.83%)	    26788.20 (-14.28%)	    23440.70	
   length=262144:     41304.50 (-35.25%)	    26883.30 ( 11.97%)	    31038.70 ( -1.63%)	    26533.40 ( 13.12%)	    30539.40	
   length=262145:     41157.90 ( 12.84%)	    25568.20 ( 45.85%)	    63229.00 (-33.90%)	    53525.00 (-13.35%)	    47220.50	
   length=524288:     81777.00 (-32.88%)	    54133.00 ( 12.04%)	    61853.30 ( -0.51%)	    52869.40 ( 14.09%)	    61542.20	
   length=524289:     81986.90 ( 14.71%)	    50562.00 ( 47.40%)	   126255.00 (-31.33%)	   105969.00 (-10.23%)	    96132.70	
  length=1048576:    163628.00 (-33.00%)	   107776.00 ( 12.00%)	   123819.00 ( -1.00%)	   105831.00 ( 14.00%)	   123170.00	
  length=1048577:    177503.00 ( 12.00%)	    98680.60 ( 51.09%)	   253068.00 (-26.00%)	   211155.00 ( -5.00%)	   201763.00	
  length=2097152:    336756.00 (-34.00%)	   224097.00 ( 11.00%)	   254575.00 ( -1.00%)	   219864.00 ( 13.00%)	   253124.00	
  length=2097153:    373590.00 (  9.00%)	   214822.00 ( 48.00%)	   506479.00 (-23.00%)	   426299.00 ( -3.00%)	   414899.00	
  length=4194304:    662606.00 (-35.00%)	   437195.00 ( 11.00%)	   497288.00 ( -2.00%)	   427614.00 ( 13.00%)	   491729.00	
  length=4194305:    697910.00 (  9.00%)	   417656.00 ( 45.00%)	  1020670.00 (-32.62%)	   856051.00 (-12.00%)	   769599.00	
  length=8388608:   1307990.00 (-34.88%)	   852030.00 ( 12.00%)	   983092.00 ( -2.00%)	   834918.00 ( 13.00%)	   969712.00	
  length=8388609:   1416420.00 (  8.70%)	   821262.00 ( 47.06%)	  2030660.00 (-30.89%)	  1708360.00 (-10.11%)	  1551450.00	
 length=16777216:   2586380.00 (-33.02%)	  1702120.00 ( 12.46%)	  1970000.00 ( -1.32%)	  1676900.00 ( 13.76%)	  1944360.00	
 length=16777217:   2796060.00 ( 13.29%)	  1627720.00 ( 49.52%)	  4079100.00 (-26.51%)	  3410640.00 ( -5.77%)	  3224440.00	
 length=33554432:   5241680.00 (-33.96%)	  3488860.00 ( 10.84%)	  4890730.00 (-24.99%)	  3474630.00 ( 11.20%)	  3912900.00	
 length=33554433:   5666550.00 ( 14.71%)	  3357520.00 ( 49.46%)	  8039630.00 (-21.01%)	  6824230.00 ( -2.72%)	  6643780.00

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Zhangxuelei (Derek)]

Hi Wilco, thaks for your rely and suggestion.

> So this makes it highly desirable to improve the generic versions
> of string functions.

We completely agree, we also like to contribute our changes in to generic version, because the most of our changes is based on generic version.

And we had some misunderstanding, we thought the ifunc is the general implenments in glibc. :)

However, there are two type patches:
1. The improvement based on generic version. There is no doubt that, we should contribute it into generic version.
2. Kunpeng specific implement, just like the memcpy patch, it is used to solve the specific of Kunpeng CPU, so we hope we can add it in ifunc to enbale this kind of patch.

In addition, is there any other work to cover if we contribute as generic version?

> Note that memchr_strlen significantly outperforms the fastest strlen
> on sizes larger than 256, so I don't think that using uminv to test
> for zeroes is the fastest approach.

Indeedly, but memchr_strlen really has poor performance before 256 bytes, and if we mix this method into current version, we may need a length count and judge it more than 256 bytes or not in each loop, is this way cheap? And we think small size is more important for strlen.

Finally, we will submit other generic implenments as soon as possible, and it would be good if you could review this two patches firstly:)

[1]. memrchr: it's already submited as generic version. see link:
https://sourceware.org/ml/libc-alpha/2019-10/msg00526.html

[2]. memcpy/memmove: it's the specific kunpeng 
https://sourceware.org/ml/libc-alpha/2019-10/msg00522.html

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Yikun Jiang]

> Finally, we will submit other generic implenments as soon as possible, and it would be good if you could review this two patches firstly:)

All patches have been submitted and updated:

[1]. [PATCH] aarch64: Optimized implementation of memrchr
https://sourceware.org/ml/libc-alpha/2019-10/msg00526.html

[2]. [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor
https://sourceware.org/ml/libc-alpha/2019-10/msg00522.html

[3] [PATCH v2] aarch64: Optimized implementation of memcmp
https://sourceware.org/ml/libc-alpha/2019-10/msg00637.html

[4] [PATCH v2] aarch64: Optimized implementation of strcpy
https://sourceware.org/ml/libc-alpha/2019-10/msg00639.html

[5] [PATCH v2] aarch64: Optimized implementation of strnlen
https://sourceware.org/ml/libc-alpha/2019-10/msg00640.html

[6] [PATCH v2] aarch64: Optimized strlen for strlen_asimd
https://sourceware.org/ml/libc-alpha/2019-10/msg00641.html


Regards,
Yikun
----------------------------------------
Jiang Yikun（Kero）
Mail: yikunkero@gmail.com

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Carlos O'Donell]

On 10/22/19 5:50 AM, Yikun Jiang wrote:
>> Finally, we will submit other generic implenments as soon as possible, and it would be good if you could review this two patches firstly:)
> 
> All patches have been submitted and updated:
> 
> [1]. [PATCH] aarch64: Optimized implementation of memrchr
> https://sourceware.org/ml/libc-alpha/2019-10/msg00526.html
> 
> [2]. [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor
> https://sourceware.org/ml/libc-alpha/2019-10/msg00522.html
> 
> [3] [PATCH v2] aarch64: Optimized implementation of memcmp
> https://sourceware.org/ml/libc-alpha/2019-10/msg00637.html
> 
> [4] [PATCH v2] aarch64: Optimized implementation of strcpy
> https://sourceware.org/ml/libc-alpha/2019-10/msg00639.html
> 
> [5] [PATCH v2] aarch64: Optimized implementation of strnlen
> https://sourceware.org/ml/libc-alpha/2019-10/msg00640.html
> 
> [6] [PATCH v2] aarch64: Optimized strlen for strlen_asimd
> https://sourceware.org/ml/libc-alpha/2019-10/msg00641.html

What is the current status of Huawei's copyright assignment
with the FSF?

-- 
Cheers,
Carlos.

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Florian Weimer]

* Carlos O'Donell:

> On 10/22/19 5:50 AM, Yikun Jiang wrote:
>>> Finally, we will submit other generic implenments as soon as
>> possible, and it would be good if you could review this two patches
>> firstly:)
>> 
>> All patches have been submitted and updated:
>> 
>> [1]. [PATCH] aarch64: Optimized implementation of memrchr
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00526.html
>> 
>> [2]. [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for
>> Kunpeng processor
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00522.html
>> 
>> [3] [PATCH v2] aarch64: Optimized implementation of memcmp
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00637.html
>> 
>> [4] [PATCH v2] aarch64: Optimized implementation of strcpy
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00639.html
>> 
>> [5] [PATCH v2] aarch64: Optimized implementation of strnlen
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00640.html
>> 
>> [6] [PATCH v2] aarch64: Optimized strlen for strlen_asimd
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00641.html
>
> What is the current status of Huawei's copyright assignment
> with the FSF?

Has there been a reply to this question?  If yes, it didn't make it to
the list.  Thanks.

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Carlos O'Donell]

On 10/26/19 5:57 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 10/22/19 5:50 AM, Yikun Jiang wrote:
>>>> Finally, we will submit other generic implenments as soon as
>>> possible, and it would be good if you could review this two patches
>>> firstly:)
>>>
>>> All patches have been submitted and updated:
>>>
>>> [1]. [PATCH] aarch64: Optimized implementation of memrchr
>>> https://sourceware.org/ml/libc-alpha/2019-10/msg00526.html
>>>
>>> [2]. [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for
>>> Kunpeng processor
>>> https://sourceware.org/ml/libc-alpha/2019-10/msg00522.html
>>>
>>> [3] [PATCH v2] aarch64: Optimized implementation of memcmp
>>> https://sourceware.org/ml/libc-alpha/2019-10/msg00637.html
>>>
>>> [4] [PATCH v2] aarch64: Optimized implementation of strcpy
>>> https://sourceware.org/ml/libc-alpha/2019-10/msg00639.html
>>>
>>> [5] [PATCH v2] aarch64: Optimized implementation of strnlen
>>> https://sourceware.org/ml/libc-alpha/2019-10/msg00640.html
>>>
>>> [6] [PATCH v2] aarch64: Optimized strlen for strlen_asimd
>>> https://sourceware.org/ml/libc-alpha/2019-10/msg00641.html
>>
>> What is the current status of Huawei's copyright assignment
>> with the FSF?
> 
> Has there been a reply to this question?  If yes, it didn't make it to
> the list.  Thanks.

I've asked fsf-records@gnu.org to clarify the pending status.

-- 
Cheers,
Carlos.

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Carlos O'Donell]

On 10/24/19 10:50 AM, Carlos O'Donell wrote:
> On 10/22/19 5:50 AM, Yikun Jiang wrote:
>>> Finally, we will submit other generic implenments as soon as possible, and it would be good if you could review this two patches firstly:)
>>
>> All patches have been submitted and updated:
>>
>> [1]. [PATCH] aarch64: Optimized implementation of memrchr
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00526.html
>>
>> [2]. [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00522.html
>>
>> [3] [PATCH v2] aarch64: Optimized implementation of memcmp
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00637.html
>>
>> [4] [PATCH v2] aarch64: Optimized implementation of strcpy
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00639.html
>>
>> [5] [PATCH v2] aarch64: Optimized implementation of strnlen
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00640.html
>>
>> [6] [PATCH v2] aarch64: Optimized strlen for strlen_asimd
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00641.html
> 
> What is the current status of Huawei's copyright assignment
> with the FSF?
> 

At present Huawei does not have an employer disclaimer.

If any of this work can be claimed by Huawei then it cannot be
integrated into glibc.

The FSF is following up with Huawei about this. There was some
confusion over exactly what kind of disclaimer, personal vs.
employer, was being requested.

My sincerest apologies for the delay as we sort this out.

-- 
Cheers,
Carlos.

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Wilco Dijkstra]

Hi Derek,

>> Note that memchr_strlen significantly outperforms the fastest strlen
>> on sizes larger than 256, so I don't think that using uminv to test
>> for zeroes is the fastest approach.
>
> Indeedly, but memchr_strlen really has poor performance before 256 bytes,

Well that means memchr can be sped up for small sizes. While it is more
complex than strlen, it shouldn't be significantly slower.

> and if we mix this method into current version, we may need a length count
> and judge it more than 256 bytes or not in each loop, is this way cheap?

That may be possible, eg. by unrolling the first 64-128 bytes and using a loop
optimized for throughput for anything larger (on the assumption that if a
string is larger than 128, it is likely much larger).

However my point was that while the uminv sequence is simple and small, it's not
the fastest, so ultimately we need to find an alternative sequence which works
better for all the generic string functions which search for a character (strlen, strnlen,
memchr, memrchr, rawmemchr, strchr, strnchr, strchrnul, strcpy, strncpy).

> And we think small size is more important for strlen.

Absolutely, handling small cases quickly is essential for all string functions.

Wilco

[PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Xuelei Zhang]

This is an optimized implementation of the memcpy and memmove on the
Huawei Kunpeng processor.

Based on the prefetch mechanism on Kunpeng arch, branch to handle 96
to 2K bytes in memcpy is written without prfm instruction. Hence,
memcpy has an optimization effect above 128 bytes, 18% improvement
for copies above 2K bytes, and 38% for larger bytes, such as 32M
bytes around.

And for memmove, there are two main changes: i) Q register is used
instead of  X register. ii) dst address is aligned instead of src
address aligned to improve store operation. Hence, memmove
implementation also has improvement above 128 bytes, that about 30%
for 2k to 8M bytes, and about 50% for 32M or more.
---
 sysdeps/aarch64/multiarch/Makefile          |   2 +-
 sysdeps/aarch64/multiarch/ifunc-impl-list.c |   4 +-
 sysdeps/aarch64/multiarch/memcpy.c          |   5 +-
 sysdeps/aarch64/multiarch/memcpy_kunpeng.S  | 468 ++++++++++++++++++++++++++++
 4 files changed, 476 insertions(+), 3 deletions(-)
 create mode 100644 sysdeps/aarch64/multiarch/memcpy_kunpeng.S

diff --git a/sysdeps/aarch64/multiarch/Makefile b/sysdeps/aarch64/multiarch/Makefile
index 4150b89a90..37ed49982d 100644
--- a/sysdeps/aarch64/multiarch/Makefile
+++ b/sysdeps/aarch64/multiarch/Makefile
@@ -1,6 +1,6 @@
 ifeq ($(subdir),string)
 sysdep_routines += memcpy_generic memcpy_thunderx memcpy_thunderx2 \
-		   memcpy_falkor memmove_falkor \
+		   memcpy_falkor memcpy_kunpeng memmove_falkor \
 		   memset_generic memset_falkor memset_emag \
 		   memchr_generic memchr_nosimd \
 		   strlen_generic strlen_asimd
diff --git a/sysdeps/aarch64/multiarch/ifunc-impl-list.c b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
index be13b916e5..dbbe19096a 100644
--- a/sysdeps/aarch64/multiarch/ifunc-impl-list.c
+++ b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
@@ -25,7 +25,7 @@
 #include <stdio.h>
 
 /* Maximum number of IFUNC implementations.  */
-#define MAX_IFUNC	4
+#define MAX_IFUNC	5
 
 size_t
 __libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array,
@@ -42,11 +42,13 @@ __libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array,
 	      IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_thunderx)
 	      IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_thunderx2)
 	      IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_falkor)
+	      IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_kunpeng)
 	      IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_generic))
   IFUNC_IMPL (i, name, memmove,
 	      IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_thunderx)
 	      IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_thunderx2)
 	      IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_falkor)
+	      IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_kunpeng)
 	      IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_generic))
   IFUNC_IMPL (i, name, memset,
 	      /* Enable this on non-falkor processors too so that other cores
diff --git a/sysdeps/aarch64/multiarch/memcpy.c b/sysdeps/aarch64/multiarch/memcpy.c
index 13796f987f..b5929e2718 100644
--- a/sysdeps/aarch64/multiarch/memcpy.c
+++ b/sysdeps/aarch64/multiarch/memcpy.c
@@ -32,9 +32,12 @@ extern __typeof (__redirect_memcpy) __memcpy_generic attribute_hidden;
 extern __typeof (__redirect_memcpy) __memcpy_thunderx attribute_hidden;
 extern __typeof (__redirect_memcpy) __memcpy_thunderx2 attribute_hidden;
 extern __typeof (__redirect_memcpy) __memcpy_falkor attribute_hidden;
+extern __typeof (__redirect_memcpy) __memcpy_kunpeng attribute_hidden;
 
 libc_ifunc (__libc_memcpy,
-            (IS_THUNDERX (midr)
+            IS_KUNPENG(midr)
+	    ?__memcpy_kunpeng
+	    : (IS_THUNDERX (midr)
 	     ? __memcpy_thunderx
 	     : (IS_FALKOR (midr) || IS_PHECDA (midr) || IS_ARES (midr)
 		? __memcpy_falkor
diff --git a/sysdeps/aarch64/multiarch/memcpy_kunpeng.S b/sysdeps/aarch64/multiarch/memcpy_kunpeng.S
new file mode 100644
index 0000000000..385f282224
--- /dev/null
+++ b/sysdeps/aarch64/multiarch/memcpy_kunpeng.S
@@ -0,0 +1,468 @@
+/* Optimized memcpy and memmove for Huawei Kunpeng processor.
+   Copyright (C) 2018-2019 Free Software Foundation, Inc.
+
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#include <sysdep.h>
+
+/* Assumptions:
+ *
+ * ARMv8-a, AArch64, unaligned accesses.
+ *
+ */
+
+#define dstin	x0
+#define src	x1
+#define count	x2
+#define dst	x3
+#define srcend	x4
+#define dstend	x5
+#define tmp2	x6
+#define tmp3	x7
+#define tmp3w   w7
+#define A_l	x6
+#define A_lw	w6
+#define A_h	x7
+#define A_hw	w7
+#define B_l	x8
+#define B_lw	w8
+#define B_h	x9
+#define C_l	x10
+#define C_h	x11
+#define D_l	x12
+#define D_h	x13
+#define E_l	src
+#define E_h	count
+#define F_l	srcend
+#define F_h	dst
+#define G_l	count
+#define G_h	dst
+#define tmp1	x14
+
+#define A_q	q0
+#define B_q	q1
+#define C_q	q2
+#define D_q	q3
+#define E_q	q4
+#define F_q	q5
+#define G_q	q6
+#define H_q	q7
+#define I_q	q16
+#define J_q	q17
+
+#define A_v	v0
+#define B_v	v1
+#define C_v	v2
+#define D_v	v3
+#define E_v	v4
+#define F_v	v5
+#define G_v	v6
+#define H_v	v7
+#define I_v	v16
+#define J_v	v17
+
+#ifndef MEMMOVE
+# define MEMMOVE memmove
+#endif
+#ifndef MEMCPY
+# define MEMCPY memcpy
+#endif
+
+#if IS_IN (libc)
+
+#undef MEMCPY
+#define MEMCPY __memcpy_kunpeng
+#undef MEMMOVE
+#define MEMMOVE __memmove_kunpeng
+
+
+/* Overlapping large forward memmoves use a loop that copies backwards.
+   Otherwise memcpy is used. Small moves branch to memcopy16 directly.
+   The longer memcpy cases fall through to the memcpy head.
+*/
+
+ENTRY_ALIGN (MEMMOVE, 6)
+
+	DELOUSE (0)
+	DELOUSE (1)
+	DELOUSE (2)
+
+	sub	tmp1, dstin, src
+	cmp	count, 512
+	ccmp	tmp1, count, 2, hi
+	b.lo	L(move_long)
+	cmp	count, 96
+	ccmp	tmp1, count, 2, hi
+	b.lo	L(move_middle)
+
+END (MEMMOVE)
+libc_hidden_builtin_def (MEMMOVE)
+
+
+/* Copies are split into 4 main cases: small copies of up to 16 bytes,
+   medium copies of 17..96 bytes which are fully unrolled. Long copies
+   of 97..2048 align dst address without prefetching. Large copies
+   of more than 2048 bytes align the destination and use load-and-merge
+   approach in the case src and dst addresses are unaligned not evenly,
+   so that, actual loads and stores are always aligned.
+   Large copies use the loops processing 64 bytes per iteration for
+   unaligned case and 128 bytes per iteration for aligned ones.
+*/
+
+#define MEMCPY_PREFETCH_LDR 640
+
+	.p2align 4
+ENTRY (MEMCPY)
+
+	DELOUSE (0)
+	DELOUSE (1)
+	DELOUSE (2)
+
+	add	srcend, src, count
+	cmp	count, 16
+	b.ls	L(memcopy16)
+	add	dstend, dstin, count
+	cmp	count, 96
+	b.hi	L(memcopy_long)
+
+	/* Medium copies: 17..96 bytes.  */
+	ldr	A_q, [src], #16
+	and	tmp1, src, 15
+	ldr	E_q, [srcend, -16]
+	cmp	count, 64
+	b.gt	L(memcpy_copy96)
+	cmp	count, 48
+	b.le	L(bytes_17_to_48)
+	/* 49..64 bytes */
+	ldp	B_q, C_q, [src]
+	str	E_q, [dstend, -16]
+	stp	A_q, B_q, [dstin]
+	str	C_q, [dstin, 32]
+	ret
+
+L(bytes_17_to_48):
+	/* 17..48 bytes*/
+	cmp	count, 32
+	b.gt	L(bytes_32_to_48)
+	/* 17..32 bytes*/
+	str	A_q, [dstin]
+	str	E_q, [dstend, -16]
+	ret
+
+L(bytes_32_to_48):
+	/* 32..48 */
+	ldr	B_q, [src]
+	str	A_q, [dstin]
+	str	E_q, [dstend, -16]
+	str	B_q, [dstin, 16]
+	ret
+
+	.p2align 4
+	/* Small copies: 0..16 bytes.  */
+L(memcopy16):
+	cmp	count, 8
+	b.lo	L(bytes_0_to_8)
+	ldr	A_l, [src]
+	ldr	A_h, [srcend, -8]
+	add	dstend, dstin, count
+	str	A_l, [dstin]
+	str	A_h, [dstend, -8]
+	ret
+	.p2align 4
+
+L(bytes_0_to_8):
+	tbz	count, 2, L(bytes_0_to_3)
+	ldr	A_lw, [src]
+	ldr	A_hw, [srcend, -4]
+	add	dstend, dstin, count
+	str	A_lw, [dstin]
+	str	A_hw, [dstend, -4]
+	ret
+
+	/* Copy 0..3 bytes.  Use a branchless sequence that copies the same
+	   byte 3 times if count==1, or the 2nd byte twice if count==2.  */
+L(bytes_0_to_3):
+	cbz	count, 1f
+	lsr	tmp1, count, 1
+	ldrb	A_lw, [src]
+	ldrb	A_hw, [srcend, -1]
+	add	dstend, dstin, count
+	ldrb	B_lw, [src, tmp1]
+	strb	B_lw, [dstin, tmp1]
+	strb	A_hw, [dstend, -1]
+	strb	A_lw, [dstin]
+1:
+	ret
+
+	.p2align 4
+
+L(memcpy_copy96):
+	/* Copying 65..96 bytes. A_q (first 16 bytes) and
+	   E_q(last 16 bytes) are already loaded. The size
+	   is large enough to benefit from aligned loads */
+	bic	src, src, 15
+	ldp	B_q, C_q, [src]
+	/* Loaded 64 bytes, second 16-bytes chunk can be
+	   overlapping with the first chunk by tmp1 bytes.
+	   Stored 16 bytes. */
+	sub	dst, dstin, tmp1
+	add	count, count, tmp1
+	/* The range of count being [65..96] becomes [65..111]
+	   after tmp [0..15] gets added to it,
+	   count now is <bytes-left-to-load>+48 */
+	cmp	count, 80
+	b.gt	L(copy96_medium)
+	ldr	D_q, [src, 32]
+	stp	B_q, C_q, [dst, 16]
+	str	D_q, [dst, 48]
+	str	A_q, [dstin]
+	str	E_q, [dstend, -16]
+	ret
+
+	.p2align 4
+L(copy96_medium):
+	ldp	D_q, G_q, [src, 32]
+	cmp	count, 96
+	b.gt	L(copy96_large)
+	stp	B_q, C_q, [dst, 16]
+	stp	D_q, G_q, [dst, 48]
+	str	A_q, [dstin]
+	str	E_q, [dstend, -16]
+	ret
+
+L(copy96_large):
+	ldr	F_q, [src, 64]
+	str	B_q, [dst, 16]
+	stp	C_q, D_q, [dst, 32]
+	stp	G_q, F_q, [dst, 64]
+	str	A_q, [dstin]
+	str	E_q, [dstend, -16]
+	ret
+
+	.p2align 4
+L(memcopy_long):
+	cmp count, 2048
+	b.ls L(copy2048_large)
+	ldr	A_q, [src], #16
+	and	tmp1, src, 15
+	bic	src, src, 15
+	ldp	B_q, C_q, [src], #32
+	sub	dst, dstin, tmp1
+	add	count, count, tmp1
+	add	dst, dst, 16
+	ldp	D_q, E_q, [src], #32
+	str	A_q, [dstin]
+
+	/* Already loaded 64+16 bytes. Check if at
+	   least 64 more bytes left */
+	subs	count, count, 64+64+16
+	b.lt	L(loop128_exit0)
+	cmp	count, MEMCPY_PREFETCH_LDR + 64 + 32
+	b.lt	L(loop128)
+	sub	count, count, MEMCPY_PREFETCH_LDR + 64 + 32
+
+	.p2align 4
+
+L(loop128_prefetch):
+	prfm	pldl1strm, [src, MEMCPY_PREFETCH_LDR]
+	ldp	F_q, G_q, [src], #32
+	stp	B_q, C_q, [dst], #32
+	ldp	H_q, I_q, [src], #32
+	prfm	pldl1strm, [src, MEMCPY_PREFETCH_LDR]
+	ldp	B_q, C_q, [src], #32
+	stp	D_q, E_q, [dst], #32
+	ldp	D_q, E_q, [src], #32
+	stp	F_q, G_q, [dst], #32
+	stp	H_q, I_q, [dst], #32
+	subs	count, count, 128
+	b.ge	L(loop128_prefetch)
+
+	add	count, count, MEMCPY_PREFETCH_LDR + 64 + 32
+	.p2align 4
+L(loop128):
+	ldp	F_q, G_q, [src], #32
+	ldp	H_q, I_q, [src], #32
+	stp	B_q, C_q, [dst], #32
+	stp	D_q, E_q, [dst], #32
+	subs	count, count, 64
+	b.lt	L(loop128_exit1)
+	ldp	B_q, C_q, [src], #32
+	ldp	D_q, E_q, [src], #32
+	stp	F_q, G_q, [dst], #32
+	stp	H_q, I_q, [dst], #32
+	subs	count, count, 64
+	b.ge	L(loop128)
+L(loop128_exit0):
+	ldp	F_q, G_q, [srcend, -64]
+	ldp	H_q, I_q, [srcend, -32]
+	stp	B_q, C_q, [dst], #32
+	stp	D_q, E_q, [dst]
+	stp	F_q, G_q, [dstend, -64]
+	stp	H_q, I_q, [dstend, -32]
+	ret
+L(loop128_exit1):
+	ldp	B_q, C_q, [srcend, -64]
+	ldp	D_q, E_q, [srcend, -32]
+	stp	F_q, G_q, [dst], #32
+	stp	H_q, I_q, [dst]
+	stp	B_q, C_q, [dstend, -64]
+	stp	D_q, E_q, [dstend, -32]
+	ret
+	
+	/* long copies: 96..2048 bytes */
+L(copy2048_large):
+	and	tmp1, dstin, 15
+	bic	dst, dstin, 15
+	ldp	D_l, D_h, [src]
+	sub	src, src, tmp1
+	add	count, count, tmp1	/* Count is now 16 too large.  */
+	ldp	A_l, A_h, [src, 16]
+	stp	D_l, D_h, [dstin]
+	ldp	B_l, B_h, [src, 32]
+	ldp	C_l, C_h, [src, 48]
+	ldp	D_l, D_h, [src, 64]!
+	subs	count, count, 128 + 16	/* Test and readjust count.  */
+	b.ls	L(last64)
+
+L(loop64):
+	stp	A_l, A_h, [dst, 16]
+	ldp	A_l, A_h, [src, 16]
+	stp	B_l, B_h, [dst, 32]
+	ldp	B_l, B_h, [src, 32]
+	stp	C_l, C_h, [dst, 48]
+	ldp	C_l, C_h, [src, 48]
+	stp	D_l, D_h, [dst, 64]
+	ldp	D_l, D_h, [src, 64]
+	add dst, dst, 64
+	add src, src, 64
+	subs	count, count, 64
+	b.hi	L(loop64)
+
+	/* Write the last full set of 64 bytes.  The remainder is at most 64
+	   bytes, so it is safe to always copy 64 bytes from the end even if
+	   there is just 1 byte left.  */
+L(last64):
+	ldp	E_l, E_h, [srcend, -64]
+	stp	A_l, A_h, [dst, 16]
+	ldp	A_l, A_h, [srcend, -48]
+	stp	B_l, B_h, [dst, 32]
+	ldp	B_l, B_h, [srcend, -32]
+	stp	C_l, C_h, [dst, 48]
+	ldp	C_l, C_h, [srcend, -16]
+	stp	D_l, D_h, [dst, 64]
+	stp	E_l, E_h, [dstend, -64]
+	stp	A_l, A_h, [dstend, -48]
+	stp	B_l, B_h, [dstend, -32]
+	stp	C_l, C_h, [dstend, -16]
+	ret
+
+	/* long move: more than 512 bytes align the dstend */
+	.p2align 4
+L(move_long):
+1:
+	add	srcend, src, count
+	add	dstend, dstin, count
+
+	and	tmp1, dstend, 15
+	ldr	D_q, [srcend, -16]
+	sub	srcend, srcend, tmp1
+	sub	count, count, tmp1
+	ldp	A_q, B_q, [srcend, -32]
+	str	D_q, [dstend, -16]
+	ldp	C_q, D_q, [srcend, -64]!
+	sub	dstend, dstend, tmp1
+	subs	count, count, 128
+	b.ls	2f
+
+	.p2align 4
+1:
+	subs	count, count, 64
+	stp	A_q, B_q, [dstend, -32]
+	ldp	A_q, B_q, [srcend, -32]
+	stp	C_q, D_q, [dstend, -64]!
+	ldp	C_q, D_q, [srcend, -64]!
+	b.hi	1b
+
+	/* Write the last full set of 64 bytes.  The remainder is at most 64
+	   bytes, so it is safe to always copy 64 bytes from the start even if
+	   there is just 1 byte left.  */
+2:
+	ldp	E_q, F_q, [src, 32]
+	ldp	G_q, H_q, [src]
+	stp	A_q, B_q, [dstend, -32]
+	stp	C_q, D_q, [dstend, -64]
+	stp	E_q, F_q, [dstin, 32]
+	stp	G_q, H_q, [dstin]
+3:	ret
+
+	/* midlle move: 96..512 bytes */
+	.p2align 4
+L(move_middle):
+	cbz	tmp1, 3f
+	add	srcend, src, count
+	prfm	PLDL1STRM, [srcend, -64]
+	add	dstend, dstin, count
+	and	tmp1, dstend, 15
+	ldr D_q, [srcend, -16]
+	sub	srcend, srcend, tmp1
+	sub	count, count, tmp1
+	ldr	A_q, [srcend, -16]
+	str	D_q, [dstend, -16]
+	ldr	B_q, [srcend, -32]
+	ldr	C_q, [srcend, -48]
+	ldr	D_q, [srcend, -64]!
+	sub	dstend, dstend, tmp1
+	subs	count, count, 128
+	b.ls	2f
+
+1:
+	str	A_q, [dstend, -16]
+	ldr	A_q, [srcend, -16]
+	str	B_q, [dstend, -32]
+	ldr	B_q, [srcend, -32]
+	str	C_q, [dstend, -48]
+	ldr	C_q, [srcend, -48]
+	str	D_q, [dstend, -64]!
+	ldr	D_q, [srcend, -64]!
+	subs	count, count, 64
+	b.hi	1b
+
+	/* Write the last full set of 64 bytes.  The remainder is at most 64
+	   bytes, so it is safe to always copy 64 bytes from the start even if
+	   there is just 1 byte left.  */
+2:
+	ldr	G_q, [src, 48]
+	str	A_q, [dstend, -16]
+	ldr	A_q, [src, 32]
+	str	B_q, [dstend, -32]
+	ldr	B_q, [src, 16]
+	str	C_q, [dstend, -48]
+	ldr	C_q, [src]
+	str	D_q, [dstend, -64]
+	str	G_q, [dstin, 48]
+	str	A_q, [dstin, 32]
+	str	B_q, [dstin, 16]
+	str	C_q, [dstin]
+3:	ret
+
+
+END (MEMCPY)
+	.section	.rodata
+	.p2align	4
+
+libc_hidden_builtin_def (MEMCPY)
+#endif
-- 
2.14.1.windows.1

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Yikun Jiang]

> Btw do you have any plans to post other string functions that you can discuss here? If so, would these
> add more ifuncs or improve the generic versions?

> Yes, memcmp, strlen, strnlen, strcpy, memrchr will be included, we will summited the patch and test results as soon as possible.

We have submitted the patches of string functions, see below:

[PATCH] aarch64: Optimized strnlen for Kunpeng processor
https://sourceware.org/ml/libc-alpha/2019-10/msg00528.html

[PATCH] aarch64: Optimized strlen for Kunpeng processor
https://sourceware.org/ml/libc-alpha/2019-10/msg00527.html

[PATCH] aarch64: Optimized implementation of memrchr
https://sourceware.org/ml/libc-alpha/2019-10/msg00526.html

[PATCH] aarch64: Optimized strcpy for Kunpeng processor.
https://sourceware.org/ml/libc-alpha/2019-10/msg00525.html

[PATCH] aarch64: Optimized memcmp for Kunpeng processor.
https://sourceware.org/ml/libc-alpha/2019-10/msg00524.html

Xuelei Zhang <zhangxuelei4@huawei.com> 于2019年10月17日周四 下午9:16写道：
>
> This is an optimized implementation of the memcpy and memmove on the
> Huawei Kunpeng processor.
>
> Based on the prefetch mechanism on Kunpeng arch, branch to handle 96
> to 2K bytes in memcpy is written without prfm instruction. Hence,
> memcpy has an optimization effect above 128 bytes, 18% improvement
> for copies above 2K bytes, and 38% for larger bytes, such as 32M
> bytes around.
>
> And for memmove, there are two main changes: i) Q register is used
> instead of  X register. ii) dst address is aligned instead of src
> address aligned to improve store operation. Hence, memmove
> implementation also has improvement above 128 bytes, that about 30%
> for 2k to 8M bytes, and about 50% for 32M or more.
> ---
>  sysdeps/aarch64/multiarch/Makefile          |   2 +-
>  sysdeps/aarch64/multiarch/ifunc-impl-list.c |   4 +-
>  sysdeps/aarch64/multiarch/memcpy.c          |   5 +-
>  sysdeps/aarch64/multiarch/memcpy_kunpeng.S  | 468 ++++++++++++++++++++++++++++
>  4 files changed, 476 insertions(+), 3 deletions(-)
>  create mode 100644 sysdeps/aarch64/multiarch/memcpy_kunpeng.S
>
> diff --git a/sysdeps/aarch64/multiarch/Makefile b/sysdeps/aarch64/multiarch/Makefile
> index 4150b89a90..37ed49982d 100644
> --- a/sysdeps/aarch64/multiarch/Makefile
> +++ b/sysdeps/aarch64/multiarch/Makefile
> @@ -1,6 +1,6 @@
>  ifeq ($(subdir),string)
>  sysdep_routines += memcpy_generic memcpy_thunderx memcpy_thunderx2 \
> -                  memcpy_falkor memmove_falkor \
> +                  memcpy_falkor memcpy_kunpeng memmove_falkor \
>                    memset_generic memset_falkor memset_emag \
>                    memchr_generic memchr_nosimd \
>                    strlen_generic strlen_asimd
> diff --git a/sysdeps/aarch64/multiarch/ifunc-impl-list.c b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
> index be13b916e5..dbbe19096a 100644
> --- a/sysdeps/aarch64/multiarch/ifunc-impl-list.c
> +++ b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
> @@ -25,7 +25,7 @@
>  #include <stdio.h>
>
>  /* Maximum number of IFUNC implementations.  */
> -#define MAX_IFUNC      4
> +#define MAX_IFUNC      5
>
>  size_t
>  __libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array,
> @@ -42,11 +42,13 @@ __libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array,
>               IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_thunderx)
>               IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_thunderx2)
>               IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_falkor)
> +             IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_kunpeng)
>               IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_generic))
>    IFUNC_IMPL (i, name, memmove,
>               IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_thunderx)
>               IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_thunderx2)
>               IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_falkor)
> +             IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_kunpeng)
>               IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_generic))
>    IFUNC_IMPL (i, name, memset,
>               /* Enable this on non-falkor processors too so that other cores
> diff --git a/sysdeps/aarch64/multiarch/memcpy.c b/sysdeps/aarch64/multiarch/memcpy.c
> index 13796f987f..b5929e2718 100644
> --- a/sysdeps/aarch64/multiarch/memcpy.c
> +++ b/sysdeps/aarch64/multiarch/memcpy.c
> @@ -32,9 +32,12 @@ extern __typeof (__redirect_memcpy) __memcpy_generic attribute_hidden;
>  extern __typeof (__redirect_memcpy) __memcpy_thunderx attribute_hidden;
>  extern __typeof (__redirect_memcpy) __memcpy_thunderx2 attribute_hidden;
>  extern __typeof (__redirect_memcpy) __memcpy_falkor attribute_hidden;
> +extern __typeof (__redirect_memcpy) __memcpy_kunpeng attribute_hidden;
>
>  libc_ifunc (__libc_memcpy,
> -            (IS_THUNDERX (midr)
> +            IS_KUNPENG(midr)
> +           ?__memcpy_kunpeng
> +           : (IS_THUNDERX (midr)
>              ? __memcpy_thunderx
>              : (IS_FALKOR (midr) || IS_PHECDA (midr) || IS_ARES (midr)
>                 ? __memcpy_falkor
> diff --git a/sysdeps/aarch64/multiarch/memcpy_kunpeng.S b/sysdeps/aarch64/multiarch/memcpy_kunpeng.S
> new file mode 100644
> index 0000000000..385f282224
> --- /dev/null
> +++ b/sysdeps/aarch64/multiarch/memcpy_kunpeng.S
> @@ -0,0 +1,468 @@
> +/* Optimized memcpy and memmove for Huawei Kunpeng processor.
> +   Copyright (C) 2018-2019 Free Software Foundation, Inc.
> +
> +   This file is part of the GNU C Library.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, see
> +   <https://www.gnu.org/licenses/>.  */
> +
> +#include <sysdep.h>
> +
> +/* Assumptions:
> + *
> + * ARMv8-a, AArch64, unaligned accesses.
> + *
> + */
> +
> +#define dstin  x0
> +#define src    x1
> +#define count  x2
> +#define dst    x3
> +#define srcend x4
> +#define dstend x5
> +#define tmp2   x6
> +#define tmp3   x7
> +#define tmp3w   w7
> +#define A_l    x6
> +#define A_lw   w6
> +#define A_h    x7
> +#define A_hw   w7
> +#define B_l    x8
> +#define B_lw   w8
> +#define B_h    x9
> +#define C_l    x10
> +#define C_h    x11
> +#define D_l    x12
> +#define D_h    x13
> +#define E_l    src
> +#define E_h    count
> +#define F_l    srcend
> +#define F_h    dst
> +#define G_l    count
> +#define G_h    dst
> +#define tmp1   x14
> +
> +#define A_q    q0
> +#define B_q    q1
> +#define C_q    q2
> +#define D_q    q3
> +#define E_q    q4
> +#define F_q    q5
> +#define G_q    q6
> +#define H_q    q7
> +#define I_q    q16
> +#define J_q    q17
> +
> +#define A_v    v0
> +#define B_v    v1
> +#define C_v    v2
> +#define D_v    v3
> +#define E_v    v4
> +#define F_v    v5
> +#define G_v    v6
> +#define H_v    v7
> +#define I_v    v16
> +#define J_v    v17
> +
> +#ifndef MEMMOVE
> +# define MEMMOVE memmove
> +#endif
> +#ifndef MEMCPY
> +# define MEMCPY memcpy
> +#endif
> +
> +#if IS_IN (libc)
> +
> +#undef MEMCPY
> +#define MEMCPY __memcpy_kunpeng
> +#undef MEMMOVE
> +#define MEMMOVE __memmove_kunpeng
> +
> +
> +/* Overlapping large forward memmoves use a loop that copies backwards.
> +   Otherwise memcpy is used. Small moves branch to memcopy16 directly.
> +   The longer memcpy cases fall through to the memcpy head.
> +*/
> +
> +ENTRY_ALIGN (MEMMOVE, 6)
> +
> +       DELOUSE (0)
> +       DELOUSE (1)
> +       DELOUSE (2)
> +
> +       sub     tmp1, dstin, src
> +       cmp     count, 512
> +       ccmp    tmp1, count, 2, hi
> +       b.lo    L(move_long)
> +       cmp     count, 96
> +       ccmp    tmp1, count, 2, hi
> +       b.lo    L(move_middle)
> +
> +END (MEMMOVE)
> +libc_hidden_builtin_def (MEMMOVE)
> +
> +
> +/* Copies are split into 4 main cases: small copies of up to 16 bytes,
> +   medium copies of 17..96 bytes which are fully unrolled. Long copies
> +   of 97..2048 align dst address without prefetching. Large copies
> +   of more than 2048 bytes align the destination and use load-and-merge
> +   approach in the case src and dst addresses are unaligned not evenly,
> +   so that, actual loads and stores are always aligned.
> +   Large copies use the loops processing 64 bytes per iteration for
> +   unaligned case and 128 bytes per iteration for aligned ones.
> +*/
> +
> +#define MEMCPY_PREFETCH_LDR 640
> +
> +       .p2align 4
> +ENTRY (MEMCPY)
> +
> +       DELOUSE (0)
> +       DELOUSE (1)
> +       DELOUSE (2)
> +
> +       add     srcend, src, count
> +       cmp     count, 16
> +       b.ls    L(memcopy16)
> +       add     dstend, dstin, count
> +       cmp     count, 96
> +       b.hi    L(memcopy_long)
> +
> +       /* Medium copies: 17..96 bytes.  */
> +       ldr     A_q, [src], #16
> +       and     tmp1, src, 15
> +       ldr     E_q, [srcend, -16]
> +       cmp     count, 64
> +       b.gt    L(memcpy_copy96)
> +       cmp     count, 48
> +       b.le    L(bytes_17_to_48)
> +       /* 49..64 bytes */
> +       ldp     B_q, C_q, [src]
> +       str     E_q, [dstend, -16]
> +       stp     A_q, B_q, [dstin]
> +       str     C_q, [dstin, 32]
> +       ret
> +
> +L(bytes_17_to_48):
> +       /* 17..48 bytes*/
> +       cmp     count, 32
> +       b.gt    L(bytes_32_to_48)
> +       /* 17..32 bytes*/
> +       str     A_q, [dstin]
> +       str     E_q, [dstend, -16]
> +       ret
> +
> +L(bytes_32_to_48):
> +       /* 32..48 */
> +       ldr     B_q, [src]
> +       str     A_q, [dstin]
> +       str     E_q, [dstend, -16]
> +       str     B_q, [dstin, 16]
> +       ret
> +
> +       .p2align 4
> +       /* Small copies: 0..16 bytes.  */
> +L(memcopy16):
> +       cmp     count, 8
> +       b.lo    L(bytes_0_to_8)
> +       ldr     A_l, [src]
> +       ldr     A_h, [srcend, -8]
> +       add     dstend, dstin, count
> +       str     A_l, [dstin]
> +       str     A_h, [dstend, -8]
> +       ret
> +       .p2align 4
> +
> +L(bytes_0_to_8):
> +       tbz     count, 2, L(bytes_0_to_3)
> +       ldr     A_lw, [src]
> +       ldr     A_hw, [srcend, -4]
> +       add     dstend, dstin, count
> +       str     A_lw, [dstin]
> +       str     A_hw, [dstend, -4]
> +       ret
> +
> +       /* Copy 0..3 bytes.  Use a branchless sequence that copies the same
> +          byte 3 times if count==1, or the 2nd byte twice if count==2.  */
> +L(bytes_0_to_3):
> +       cbz     count, 1f
> +       lsr     tmp1, count, 1
> +       ldrb    A_lw, [src]
> +       ldrb    A_hw, [srcend, -1]
> +       add     dstend, dstin, count
> +       ldrb    B_lw, [src, tmp1]
> +       strb    B_lw, [dstin, tmp1]
> +       strb    A_hw, [dstend, -1]
> +       strb    A_lw, [dstin]
> +1:
> +       ret
> +
> +       .p2align 4
> +
> +L(memcpy_copy96):
> +       /* Copying 65..96 bytes. A_q (first 16 bytes) and
> +          E_q(last 16 bytes) are already loaded. The size
> +          is large enough to benefit from aligned loads */
> +       bic     src, src, 15
> +       ldp     B_q, C_q, [src]
> +       /* Loaded 64 bytes, second 16-bytes chunk can be
> +          overlapping with the first chunk by tmp1 bytes.
> +          Stored 16 bytes. */
> +       sub     dst, dstin, tmp1
> +       add     count, count, tmp1
> +       /* The range of count being [65..96] becomes [65..111]
> +          after tmp [0..15] gets added to it,
> +          count now is <bytes-left-to-load>+48 */
> +       cmp     count, 80
> +       b.gt    L(copy96_medium)
> +       ldr     D_q, [src, 32]
> +       stp     B_q, C_q, [dst, 16]
> +       str     D_q, [dst, 48]
> +       str     A_q, [dstin]
> +       str     E_q, [dstend, -16]
> +       ret
> +
> +       .p2align 4
> +L(copy96_medium):
> +       ldp     D_q, G_q, [src, 32]
> +       cmp     count, 96
> +       b.gt    L(copy96_large)
> +       stp     B_q, C_q, [dst, 16]
> +       stp     D_q, G_q, [dst, 48]
> +       str     A_q, [dstin]
> +       str     E_q, [dstend, -16]
> +       ret
> +
> +L(copy96_large):
> +       ldr     F_q, [src, 64]
> +       str     B_q, [dst, 16]
> +       stp     C_q, D_q, [dst, 32]
> +       stp     G_q, F_q, [dst, 64]
> +       str     A_q, [dstin]
> +       str     E_q, [dstend, -16]
> +       ret
> +
> +       .p2align 4
> +L(memcopy_long):
> +       cmp count, 2048
> +       b.ls L(copy2048_large)
> +       ldr     A_q, [src], #16
> +       and     tmp1, src, 15
> +       bic     src, src, 15
> +       ldp     B_q, C_q, [src], #32
> +       sub     dst, dstin, tmp1
> +       add     count, count, tmp1
> +       add     dst, dst, 16
> +       ldp     D_q, E_q, [src], #32
> +       str     A_q, [dstin]
> +
> +       /* Already loaded 64+16 bytes. Check if at
> +          least 64 more bytes left */
> +       subs    count, count, 64+64+16
> +       b.lt    L(loop128_exit0)
> +       cmp     count, MEMCPY_PREFETCH_LDR + 64 + 32
> +       b.lt    L(loop128)
> +       sub     count, count, MEMCPY_PREFETCH_LDR + 64 + 32
> +
> +       .p2align 4
> +
> +L(loop128_prefetch):
> +       prfm    pldl1strm, [src, MEMCPY_PREFETCH_LDR]
> +       ldp     F_q, G_q, [src], #32
> +       stp     B_q, C_q, [dst], #32
> +       ldp     H_q, I_q, [src], #32
> +       prfm    pldl1strm, [src, MEMCPY_PREFETCH_LDR]
> +       ldp     B_q, C_q, [src], #32
> +       stp     D_q, E_q, [dst], #32
> +       ldp     D_q, E_q, [src], #32
> +       stp     F_q, G_q, [dst], #32
> +       stp     H_q, I_q, [dst], #32
> +       subs    count, count, 128
> +       b.ge    L(loop128_prefetch)
> +
> +       add     count, count, MEMCPY_PREFETCH_LDR + 64 + 32
> +       .p2align 4
> +L(loop128):
> +       ldp     F_q, G_q, [src], #32
> +       ldp     H_q, I_q, [src], #32
> +       stp     B_q, C_q, [dst], #32
> +       stp     D_q, E_q, [dst], #32
> +       subs    count, count, 64
> +       b.lt    L(loop128_exit1)
> +       ldp     B_q, C_q, [src], #32
> +       ldp     D_q, E_q, [src], #32
> +       stp     F_q, G_q, [dst], #32
> +       stp     H_q, I_q, [dst], #32
> +       subs    count, count, 64
> +       b.ge    L(loop128)
> +L(loop128_exit0):
> +       ldp     F_q, G_q, [srcend, -64]
> +       ldp     H_q, I_q, [srcend, -32]
> +       stp     B_q, C_q, [dst], #32
> +       stp     D_q, E_q, [dst]
> +       stp     F_q, G_q, [dstend, -64]
> +       stp     H_q, I_q, [dstend, -32]
> +       ret
> +L(loop128_exit1):
> +       ldp     B_q, C_q, [srcend, -64]
> +       ldp     D_q, E_q, [srcend, -32]
> +       stp     F_q, G_q, [dst], #32
> +       stp     H_q, I_q, [dst]
> +       stp     B_q, C_q, [dstend, -64]
> +       stp     D_q, E_q, [dstend, -32]
> +       ret
> +
> +       /* long copies: 96..2048 bytes */
> +L(copy2048_large):
> +       and     tmp1, dstin, 15
> +       bic     dst, dstin, 15
> +       ldp     D_l, D_h, [src]
> +       sub     src, src, tmp1
> +       add     count, count, tmp1      /* Count is now 16 too large.  */
> +       ldp     A_l, A_h, [src, 16]
> +       stp     D_l, D_h, [dstin]
> +       ldp     B_l, B_h, [src, 32]
> +       ldp     C_l, C_h, [src, 48]
> +       ldp     D_l, D_h, [src, 64]!
> +       subs    count, count, 128 + 16  /* Test and readjust count.  */
> +       b.ls    L(last64)
> +
> +L(loop64):
> +       stp     A_l, A_h, [dst, 16]
> +       ldp     A_l, A_h, [src, 16]
> +       stp     B_l, B_h, [dst, 32]
> +       ldp     B_l, B_h, [src, 32]
> +       stp     C_l, C_h, [dst, 48]
> +       ldp     C_l, C_h, [src, 48]
> +       stp     D_l, D_h, [dst, 64]
> +       ldp     D_l, D_h, [src, 64]
> +       add dst, dst, 64
> +       add src, src, 64
> +       subs    count, count, 64
> +       b.hi    L(loop64)
> +
> +       /* Write the last full set of 64 bytes.  The remainder is at most 64
> +          bytes, so it is safe to always copy 64 bytes from the end even if
> +          there is just 1 byte left.  */
> +L(last64):
> +       ldp     E_l, E_h, [srcend, -64]
> +       stp     A_l, A_h, [dst, 16]
> +       ldp     A_l, A_h, [srcend, -48]
> +       stp     B_l, B_h, [dst, 32]
> +       ldp     B_l, B_h, [srcend, -32]
> +       stp     C_l, C_h, [dst, 48]
> +       ldp     C_l, C_h, [srcend, -16]
> +       stp     D_l, D_h, [dst, 64]
> +       stp     E_l, E_h, [dstend, -64]
> +       stp     A_l, A_h, [dstend, -48]
> +       stp     B_l, B_h, [dstend, -32]
> +       stp     C_l, C_h, [dstend, -16]
> +       ret
> +
> +       /* long move: more than 512 bytes align the dstend */
> +       .p2align 4
> +L(move_long):
> +1:
> +       add     srcend, src, count
> +       add     dstend, dstin, count
> +
> +       and     tmp1, dstend, 15
> +       ldr     D_q, [srcend, -16]
> +       sub     srcend, srcend, tmp1
> +       sub     count, count, tmp1
> +       ldp     A_q, B_q, [srcend, -32]
> +       str     D_q, [dstend, -16]
> +       ldp     C_q, D_q, [srcend, -64]!
> +       sub     dstend, dstend, tmp1
> +       subs    count, count, 128
> +       b.ls    2f
> +
> +       .p2align 4
> +1:
> +       subs    count, count, 64
> +       stp     A_q, B_q, [dstend, -32]
> +       ldp     A_q, B_q, [srcend, -32]
> +       stp     C_q, D_q, [dstend, -64]!
> +       ldp     C_q, D_q, [srcend, -64]!
> +       b.hi    1b
> +
> +       /* Write the last full set of 64 bytes.  The remainder is at most 64
> +          bytes, so it is safe to always copy 64 bytes from the start even if
> +          there is just 1 byte left.  */
> +2:
> +       ldp     E_q, F_q, [src, 32]
> +       ldp     G_q, H_q, [src]
> +       stp     A_q, B_q, [dstend, -32]
> +       stp     C_q, D_q, [dstend, -64]
> +       stp     E_q, F_q, [dstin, 32]
> +       stp     G_q, H_q, [dstin]
> +3:     ret
> +
> +       /* midlle move: 96..512 bytes */
> +       .p2align 4
> +L(move_middle):
> +       cbz     tmp1, 3f
> +       add     srcend, src, count
> +       prfm    PLDL1STRM, [srcend, -64]
> +       add     dstend, dstin, count
> +       and     tmp1, dstend, 15
> +       ldr D_q, [srcend, -16]
> +       sub     srcend, srcend, tmp1
> +       sub     count, count, tmp1
> +       ldr     A_q, [srcend, -16]
> +       str     D_q, [dstend, -16]
> +       ldr     B_q, [srcend, -32]
> +       ldr     C_q, [srcend, -48]
> +       ldr     D_q, [srcend, -64]!
> +       sub     dstend, dstend, tmp1
> +       subs    count, count, 128
> +       b.ls    2f
> +
> +1:
> +       str     A_q, [dstend, -16]
> +       ldr     A_q, [srcend, -16]
> +       str     B_q, [dstend, -32]
> +       ldr     B_q, [srcend, -32]
> +       str     C_q, [dstend, -48]
> +       ldr     C_q, [srcend, -48]
> +       str     D_q, [dstend, -64]!
> +       ldr     D_q, [srcend, -64]!
> +       subs    count, count, 64
> +       b.hi    1b
> +
> +       /* Write the last full set of 64 bytes.  The remainder is at most 64
> +          bytes, so it is safe to always copy 64 bytes from the start even if
> +          there is just 1 byte left.  */
> +2:
> +       ldr     G_q, [src, 48]
> +       str     A_q, [dstend, -16]
> +       ldr     A_q, [src, 32]
> +       str     B_q, [dstend, -32]
> +       ldr     B_q, [src, 16]
> +       str     C_q, [dstend, -48]
> +       ldr     C_q, [src]
> +       str     D_q, [dstend, -64]
> +       str     G_q, [dstin, 48]
> +       str     A_q, [dstin, 32]
> +       str     B_q, [dstin, 16]
> +       str     C_q, [dstin]
> +3:     ret
> +
> +
> +END (MEMCPY)
> +       .section        .rodata
> +       .p2align        4
> +
> +libc_hidden_builtin_def (MEMCPY)
> +#endif
> --
> 2.14.1.windows.1
>
>

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Wilco Dijkstra]

Hi Yikun,

>> Btw do you have any plans to post other string functions that you can discuss here? If so, would these
>> add more ifuncs or improve the generic versions?
>
> Yes, memcmp, strlen, strnlen, strcpy, memrchr will be included, we will summited the patch and test results as soon as possible.
>
>We have submitted the patches of string functions, see below:

Thanks, that makes it easier to discuss in more detail. So in almost all cases these
patches add new ifuncs. There are general issues with ifuncs which make adding
lots of similar ifuncs a bad idea. The key problem is that ifuncs are not used inside
GLIBC itself. For example the strstr implementation benefits from a fast memcmp
but it always uses the generic memcmp, so it won't get any gains from the Kunpeng
optimized one.

So this makes it highly desirable to improve the generic versions of string functions.
From what I see, all of the changes are fairly simple and generic improvements, so
can be done easily to the generic versions. I think it would be a very bad idea to add
lots of ifunc variants which are almost identical to existing versions and differ in
minor details like unrolling.

For example strlen and memcmp add unrolling to existing code. Note that memchr_strlen
significantly outperforms the fastest strlen on sizes larger than 256, so I don't think that
using uminv to test for zeroes is the fastest approach.

Cheers,
Wilco

Re: [PATCH v2 2/2] aarch64: Optimized memcpy and memmove for Kunpeng processor

[Wilco Dijkstra]

Hi Xuelei,

In order to select the right memmove implementation, multiarch/memmove.c needs
similar changes as multiarch/memcpy.c.

Also since the memmove entry sequence does both check for medium and large cases, the
full overlap check should be done in both. Currently only sizes 96-512 benefit, not the
move_long case:

+       /* long move: more than 512 bytes align the dstend */
+       .p2align 4
+L(move_long):
+1:
+       add     srcend, src, count
+       add     dstend, dstin, count

This should do the same as move_middle:

+L(move_middle):
+       cbz     tmp1, 3f

Wilco