diff mbox series

aarch64: Revert "aarch64: Optimized implementation of strnlen" [BZ #25825]

Message ID 3f68f5162f10451ebe487e4047a56b82@huawei.com
State New
Headers show
Series aarch64: Revert "aarch64: Optimized implementation of strnlen" [BZ #25825] | expand

Commit Message

zhuyan (M) April 15, 2020, 1:32 p.m. UTC 
After commit 2911cb68ed3d6c515ad1979237e74e1fefab3674("aarch64:
Optimized implementation of strnlen"), there is a problem when calling the strnlen interface to handle the string length of 9 or more

This reverts commit 2911cb68ed3d6c515ad1979237e74e1fefab3674.
---
 sysdeps/aarch64/strnlen.S | 52 +----------------------------------------------
 1 file changed, 1 insertion(+), 51 deletions(-)

--
2.12.3

Comments

Florian Weimer April 15, 2020, 1:35 p.m. UTC | #1 
* zhuyan:

> After commit 2911cb68ed3d6c515ad1979237e74e1fefab3674("aarch64:
> Optimized implementation of strnlen"), there is a problem when calling the strnlen interface to handle the string length of 9 or more
>
> This reverts commit 2911cb68ed3d6c515ad1979237e74e1fefab3674.

Do you have a test case for this bug?  Or is it already caught by the
test suite?

Thanks,
Florian
Andreas Schwab April 15, 2020, 1:46 p.m. UTC | #2 
On Apr 15 2020, Florian Weimer via Libc-alpha wrote:

> * zhuyan:
>
>> After commit 2911cb68ed3d6c515ad1979237e74e1fefab3674("aarch64:
>> Optimized implementation of strnlen"), there is a problem when calling the strnlen interface to handle the string length of 9 or more
>>
>> This reverts commit 2911cb68ed3d6c515ad1979237e74e1fefab3674.
>
> Do you have a test case for this bug?  Or is it already caught by the
> test suite?

https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/glibc:testsuite/a/aarch64
has no related failures.

Andreas.
diff mbox series

Patch

diff --git a/sysdeps/aarch64/strnlen.S b/sysdeps/aarch64/strnlen.S index 5981247dd9..2b55eda6db 100644
--- a/sysdeps/aarch64/strnlen.S
+++ b/sysdeps/aarch64/strnlen.S
@@ -45,11 +45,6 @@ 
 #define pos		x13
 #define limit_wd	x14
 
-#define dataq		q2
-#define datav		v2
-#define datab2		b3
-#define dataq2		q3
-#define datav2		v3
 #define REP8_01 0x0101010101010101
 #define REP8_7f 0x7f7f7f7f7f7f7f7f
 #define REP8_80 0x8080808080808080
@@ -76,7 +71,7 @@  ENTRY_ALIGN_AND_PAD (__strnlen, 6, 9)
 	   cycle, as we get much better parallelism out of the operations.  */
 
 	/* Start of critial section -- keep to one 64Byte cache line.  */
-
+L(loop):
 	ldp	data1, data2, [src], #16
 L(realigned):
 	sub	tmp1, data1, zeroones
@@ -124,51 +119,6 @@  L(nul_in_data2):
 	csel	len, len, limit, ls		/* Return the lower value.  */
 	RET
 
-L(loop):
-	ldr	dataq, [src], #16
-	uminv	datab2, datav.16b
-	mov	tmp1, datav2.d[0]
-	subs	limit_wd, limit_wd, #1
-	ccmp	tmp1, #0, #4, pl	/* NZCV = 0000  */
-	b.eq	L(loop_end)
-	ldr	dataq, [src], #16
-	uminv	datab2, datav.16b
-	mov	tmp1, datav2.d[0]
-	subs	limit_wd, limit_wd, #1
-	ccmp	tmp1, #0, #4, pl	/* NZCV = 0000  */
-	b.ne	L(loop)
-L(loop_end):
-	/* End of critical section -- keep to one 64Byte cache line.  */
-
-	cbnz	tmp1, L(hit_limit)	/* No null in final Qword.  */
-
-	/* We know there's a null in the final Qword.  The easiest thing
-	   to do now is work out the length of the string and return
-	   MIN (len, limit).  */
-
-#ifdef __AARCH64EB__
-	rev64	datav.16b, datav.16b
-#endif
-	/* Set te NULL byte as 0xff and the rest as 0x00, move the data into a
-	   pair of scalars and then compute the length from the earliest NULL
-	   byte.  */
-
-	cmeq	datav.16b, datav.16b, #0
-	mov	data1, datav.d[0]
-	mov	data2, datav.d[1]
-	cmp	data1, 0
-	csel	data1, data1, data2, ne
-	sub	len, src, srcin
-	sub	len, len, #16
-	rev	data1, data1
-	add	tmp2, len, 8
-	clz	tmp1, data1
-	csel	len, len, tmp2, ne
-	add	len, len, tmp1, lsr 3
-	cmp	len, limit
-	csel	len, len, limit, ls		/* Return the lower value.  */
-	RET
-
 L(misaligned):
 	/* Deal with a partial first word.
 	   We're doing two things in parallel here;