[v2,2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core

Message ID 20240508165924.874710-2-quic_apinski@quicinc.com
State Superseded, archived
Headers
Series [v2,1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core |

Checks

Context Check Description
redhat-pt-bot/TryBot-apply_patch success Patch applied to master at the time it was sent
redhat-pt-bot/TryBot-32bit success Build for i686
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_glibc_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_glibc_check--master-arm success Testing passed

Commit Message

Andrew Pinski May 8, 2024, 4:59 p.m. UTC
  Qualcom's new core, oryon-1, has a different characteristics for
memset than the current versions of memset. For non-zero, larger
sizes, using GPRs rather than the SIMD stores is ~30% faster.
For even larger sizes, using the nontemporal stores is needed
not to polute the L1/L2 caches.

For zero values, using `dc zva` should be used. Since we
know the size will always be 64 bytes, we don't need to figure
out the size there.

I started with the emag memset and added back the `dc zva` code.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
---
 sysdeps/aarch64/multiarch/Makefile          |   1 +
 sysdeps/aarch64/multiarch/ifunc-impl-list.c |   1 +
 sysdeps/aarch64/multiarch/memset.c          |   5 +
 sysdeps/aarch64/multiarch/memset_oryon1.S   | 176 ++++++++++++++++++++
 4 files changed, 183 insertions(+)
 create mode 100644 sysdeps/aarch64/multiarch/memset_oryon1.S
  

Comments

Florian Weimer May 13, 2024, 1:48 p.m. UTC | #1
* Andrew Pinski:

> Qualcom's new core, oryon-1, has a different characteristics for
> memset than the current versions of memset. For non-zero, larger
> sizes, using GPRs rather than the SIMD stores is ~30% faster.
> For even larger sizes, using the nontemporal stores is needed
> not to polute the L1/L2 caches.

NB: Commit subject has 0ryon with a zero instead of an O.  Not sure if
this is intentional.

Thanks,
Florian
  
Andrew Pinski May 14, 2024, 6:19 a.m. UTC | #2
> -----Original Message-----
> From: Florian Weimer <fweimer@redhat.com>
> Sent: Monday, May 13, 2024 6:49 AM
> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> Cc: libc-alpha@sourceware.org
> Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's
> 0ryon-1 core
> 
> * Andrew Pinski:
> 
> > Qualcom's new core, oryon-1, has a different characteristics for
> > memset than the current versions of memset. For non-zero, larger
> > sizes, using GPRs rather than the SIMD stores is ~30% faster.
> > For even larger sizes, using the nontemporal stores is needed not to
> > polute the L1/L2 caches.
> 
> NB: Commit subject has 0ryon with a zero instead of an O.  Not sure if this is
> intentional.

No, it was a typo, the `o` is right below the 0 on the keyboard and I did not notice that typo until you mentioned it.
Should I submit a new patch with the typo fixed in the subject line or will the person committing it will fix it?


Thanks,
Andrew Pinski

> 
> Thanks,
> Florian
  
Florian Weimer May 14, 2024, 7:32 a.m. UTC | #3
* Andrew Pinski:

> +L(try_zva):
> +	/* Write the first and last 64 byte aligned block using stp rather
> +	   than using DC ZVA.  This is faster on some cores.
> +	 */

The “some cores” part seems outdated if it's just a memset for the
Oryon-1 core (singulare).  This comment and some others, for example

> +	/*
> +	 * Adjust count and bias for loop. By subtracting extra 1 from count,
> +	 * it is easy to use tbz instruction to check whether loop tailing
> +	 * count is less than 33 bytes, so as to bypass 2 unnecessary stps.
> +	 */

do not use GNU style.  This one is GNU style:

> +	/* Set 64..96 bytes.  Write 64 bytes from the start and
> +	   32 bytes from the end.  */

No separate start end end lines, no * indentation, space after the final .

Thanks,
Florian
  
Florian Weimer May 14, 2024, 7:37 a.m. UTC | #4
* Andrew Pinski:

>> -----Original Message-----
>> From: Florian Weimer <fweimer@redhat.com>
>> Sent: Monday, May 13, 2024 6:49 AM
>> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
>> Cc: libc-alpha@sourceware.org
>> Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's
>> 0ryon-1 core
>> 
>> * Andrew Pinski:
>> 
>> > Qualcom's new core, oryon-1, has a different characteristics for
>> > memset than the current versions of memset. For non-zero, larger
>> > sizes, using GPRs rather than the SIMD stores is ~30% faster.
>> > For even larger sizes, using the nontemporal stores is needed not to
>> > polute the L1/L2 caches.
>> 
>> NB: Commit subject has 0ryon with a zero instead of an O.  Not sure
>> if this is intentional.
>
> No, it was a typo, the `o` is right below the 0 on the keyboard and I
> did not notice that typo until you mentioned it.  Should I submit a
> new patch with the typo fixed in the subject line or will the person
> committing it will fix it?

If found some other nits, so maybe repost it?  We can then consider
applying it.

I suppose you will be around to maintain these implementations?

Thanks,
Florian
  
Andrew Pinski May 14, 2024, 7:40 a.m. UTC | #5
> -----Original Message-----
> From: Florian Weimer <fweimer@redhat.com>
> Sent: Tuesday, May 14, 2024 12:32 AM
> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> Cc: libc-alpha@sourceware.org
> Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's
> 0ryon-1 core
> 
> * Andrew Pinski:
> 
> > +L(try_zva):
> > +	/* Write the first and last 64 byte aligned block using stp rather
> > +	   than using DC ZVA.  This is faster on some cores.
> > +	 */
> 
> The “some cores” part seems outdated if it's just a memset for the
> Oryon-1 core (singulare).  This comment and some others, for example

Will fix.

> 
> > +	/*
> > +	 * Adjust count and bias for loop. By subtracting extra 1 from count,
> > +	 * it is easy to use tbz instruction to check whether loop tailing
> > +	 * count is less than 33 bytes, so as to bypass 2 unnecessary stps.
> > +	 */
> 
> do not use GNU style.  This one is GNU style:

This was copied exactly from memset_emag.S which has the style issue in it too. It was in 9627ab99b50 commit where this comment was introduced which copied from memset_base64.S.
Should we fix the other files or just the new files? Because it seems like having one version being based on the other once and then changing the style in one case but not the other seems wrong.
I suspect there many more GNU comment style issues in the aarch64 mem* functions even.

Thanks,
Andrew Pinski

> 
> > +	/* Set 64..96 bytes.  Write 64 bytes from the start and
> > +	   32 bytes from the end.  */
> 
> No separate start end end lines, no * indentation, space after the final .
> 
> Thanks,
> Florian
  
Andrew Pinski May 14, 2024, 7:47 a.m. UTC | #6
> -----Original Message-----
> From: Florian Weimer <fweimer@redhat.com>
> Sent: Tuesday, May 14, 2024 12:37 AM
> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> Cc: libc-alpha@sourceware.org
> Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's
> 0ryon-1 core
> 
> * Andrew Pinski:
> 
> >> -----Original Message-----
> >> From: Florian Weimer <fweimer@redhat.com>
> >> Sent: Monday, May 13, 2024 6:49 AM
> >> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> >> Cc: libc-alpha@sourceware.org
> >> Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's
> >> 0ryon-1 core
> >>
> >> * Andrew Pinski:
> >>
> >> > Qualcom's new core, oryon-1, has a different characteristics for
> >> > memset than the current versions of memset. For non-zero, larger
> >> > sizes, using GPRs rather than the SIMD stores is ~30% faster.
> >> > For even larger sizes, using the nontemporal stores is needed not
> >> > to polute the L1/L2 caches.
> >>
> >> NB: Commit subject has 0ryon with a zero instead of an O.  Not sure
> >> if this is intentional.
> >
> > No, it was a typo, the `o` is right below the 0 on the keyboard and I
> > did not notice that typo until you mentioned it.  Should I submit a
> > new patch with the typo fixed in the subject line or will the person
> > committing it will fix it?
> 
> If found some other nits, so maybe repost it?  We can then consider applying
> it.

Ok, I will fix it and resubmit.

> 
> I suppose you will be around to maintain these implementations?

Yes I will be around to maintain these implementations though is this a new requirement since it was not asked of the other implementations that were added in previous years. 

Thanks,
Andrew Pinski

> 
> Thanks,
> Florian
  
Florian Weimer May 14, 2024, 9:10 a.m. UTC | #7
* Andrew Pinski:

> Yes I will be around to maintain these implementations though is this
> a new requirement since it was not asked of the other implementations
> that were added in previous years.

The other implementations where approved or integrated by the aarch64
maintainers.  This is likely not going to happen here: if we merge your
changes, it will not be with their approval (but obviously also not over
their objections).

Thanks,
Florian
  
Andrew Pinski May 22, 2024, 11:01 p.m. UTC | #8
> -----Original Message-----
> From: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> Sent: Tuesday, May 14, 2024 12:41 AM
> To: Florian Weimer <fweimer@redhat.com>; Andrew Pinski
> (QUIC) <quic_apinski@quicinc.com>
> Cc: libc-alpha@sourceware.org
> Subject: RE: [PATCH v2 2/2] Aarch64: Add new memset for
> Qualcomm's 0ryon-1 core
> 
> > -----Original Message-----
> > From: Florian Weimer <fweimer@redhat.com>
> > Sent: Tuesday, May 14, 2024 12:32 AM
> > To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> > Cc: libc-alpha@sourceware.org
> > Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for
> Qualcomm's
> > 0ryon-1 core
> >
> > * Andrew Pinski:
> >
> > > +L(try_zva):
> > > +	/* Write the first and last 64 byte aligned block using
> stp rather
> > > +	   than using DC ZVA.  This is faster on some cores.
> > > +	 */
> >
> > The “some cores” part seems outdated if it's just a memset
> for the
> > Oryon-1 core (singulare).  This comment and some others,
> for example
> 
> Will fix.
> 
> >
> > > +	/*
> > > +	 * Adjust count and bias for loop. By subtracting extra 1
> from count,
> > > +	 * it is easy to use tbz instruction to check whether
> loop tailing
> > > +	 * count is less than 33 bytes, so as to bypass 2
> unnecessary stps.
> > > +	 */
> >
> > do not use GNU style.  This one is GNU style:
> 
> This was copied exactly from memset_emag.S which has the
> style issue in it too. It was in 9627ab99b50 commit where this
> comment was introduced which copied from
> memset_base64.S.
> Should we fix the other files or just the new files? Because it
> seems like having one version being based on the other once
> and then changing the style in one case but not the other
> seems wrong.
> I suspect there many more GNU comment style issues in the
> aarch64 mem* functions even.

Ping on this question? I don't want to update my patch until I get a further clarification on if the other files should be fixed in a similar way or if it is ok having the two files have different coding styles or should we just keep them the same.
I don't care one way or the other, I will implement it either way. Though it seems like it should be up to the maintainer to fix up coding style issues of what was already there; it should not be the burden of person submitting code that is doing copying.

Thanks,
Andrew Pinski

> 
> Thanks,
> Andrew Pinski
> 
> >
> > > +	/* Set 64..96 bytes.  Write 64 bytes from the start and
> > > +	   32 bytes from the end.  */
> >
> > No separate start end end lines, no * indentation, space after
> the final .
> >
> > Thanks,
> > Florian
>
  
Adhemerval Zanella Netto May 23, 2024, 1:08 p.m. UTC | #9
On 22/05/24 20:01, Andrew Pinski (QUIC) wrote:
>> -----Original Message-----
>> From: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
>> Sent: Tuesday, May 14, 2024 12:41 AM
>> To: Florian Weimer <fweimer@redhat.com>; Andrew Pinski
>> (QUIC) <quic_apinski@quicinc.com>
>> Cc: libc-alpha@sourceware.org
>> Subject: RE: [PATCH v2 2/2] Aarch64: Add new memset for
>> Qualcomm's 0ryon-1 core
>>
>>> -----Original Message-----
>>> From: Florian Weimer <fweimer@redhat.com>
>>> Sent: Tuesday, May 14, 2024 12:32 AM
>>> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
>>> Cc: libc-alpha@sourceware.org
>>> Subject: Re: [PATCH v2 2/2] Aarch64: Add new memset for
>> Qualcomm's
>>> 0ryon-1 core
>>>
>>> * Andrew Pinski:
>>>
>>>> +L(try_zva):
>>>> +	/* Write the first and last 64 byte aligned block using
>> stp rather
>>>> +	   than using DC ZVA.  This is faster on some cores.
>>>> +	 */
>>>
>>> The “some cores” part seems outdated if it's just a memset
>> for the
>>> Oryon-1 core (singulare).  This comment and some others,
>> for example
>>
>> Will fix.
>>
>>>
>>>> +	/*
>>>> +	 * Adjust count and bias for loop. By subtracting extra 1
>> from count,
>>>> +	 * it is easy to use tbz instruction to check whether
>> loop tailing
>>>> +	 * count is less than 33 bytes, so as to bypass 2
>> unnecessary stps.
>>>> +	 */
>>>
>>> do not use GNU style.  This one is GNU style:
>>
>> This was copied exactly from memset_emag.S which has the
>> style issue in it too. It was in 9627ab99b50 commit where this
>> comment was introduced which copied from
>> memset_base64.S.
>> Should we fix the other files or just the new files? Because it
>> seems like having one version being based on the other once
>> and then changing the style in one case but not the other
>> seems wrong.
>> I suspect there many more GNU comment style issues in the
>> aarch64 mem* functions even.
> 
> Ping on this question? I don't want to update my patch until I get a further clarification on if the other files should be fixed in a similar way or if it is ok having the two files have different coding styles or should we just keep them the same.
> I don't care one way or the other, I will implement it either way. Though it seems like it should be up to the maintainer to fix up coding style issues of what was already there; it should not be the burden of person submitting code that is doing copying.

I see these specific coding styles as non-blocking issues, my expectation
would be to you fix it locally and install the patch.  If you want to fix
it on other files it would be good as well, but also not a requirement.

My understanding was that it was not caught back when EMAG implementation
were added.
  

Patch

diff --git a/sysdeps/aarch64/multiarch/Makefile b/sysdeps/aarch64/multiarch/Makefile
index ef5ea9ab8c..3e251cc234 100644
--- a/sysdeps/aarch64/multiarch/Makefile
+++ b/sysdeps/aarch64/multiarch/Makefile
@@ -15,6 +15,7 @@  sysdep_routines += \
   memset_generic \
   memset_kunpeng \
   memset_mops \
+  memset_oryon1 \
   memset_zva64 \
   strlen_asimd \
   strlen_generic \
diff --git a/sysdeps/aarch64/multiarch/ifunc-impl-list.c b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
index 65c56b9b41..b2fda541f9 100644
--- a/sysdeps/aarch64/multiarch/ifunc-impl-list.c
+++ b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
@@ -56,6 +56,7 @@  __libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array,
 	      IFUNC_IMPL_ADD (array, i, memmove, 1, __memmove_generic))
   IFUNC_IMPL (i, name, memset,
 	      IFUNC_IMPL_ADD (array, i, memset, (zva_size == 64), __memset_zva64)
+	      IFUNC_IMPL_ADD (array, i, memset, (zva_size == 64), __memset_oryon1)
 	      IFUNC_IMPL_ADD (array, i, memset, 1, __memset_emag)
 	      IFUNC_IMPL_ADD (array, i, memset, 1, __memset_kunpeng)
 #if HAVE_AARCH64_SVE_ASM
diff --git a/sysdeps/aarch64/multiarch/memset.c b/sysdeps/aarch64/multiarch/memset.c
index 34bce045dd..bd063c16c9 100644
--- a/sysdeps/aarch64/multiarch/memset.c
+++ b/sysdeps/aarch64/multiarch/memset.c
@@ -1,5 +1,6 @@ 
 /* Multiple versions of memset. AARCH64 version.
    Copyright (C) 2017-2024 Free Software Foundation, Inc.
+   Copyright The GNU Toolchain Authors.
    This file is part of the GNU C Library.
 
    The GNU C Library is free software; you can redistribute it and/or
@@ -34,6 +35,7 @@  extern __typeof (__redirect_memset) __memset_kunpeng attribute_hidden;
 extern __typeof (__redirect_memset) __memset_a64fx attribute_hidden;
 extern __typeof (__redirect_memset) __memset_generic attribute_hidden;
 extern __typeof (__redirect_memset) __memset_mops attribute_hidden;
+extern __typeof (__redirect_memset) __memset_oryon1 attribute_hidden;
 
 static inline __typeof (__redirect_memset) *
 select_memset_ifunc (void)
@@ -49,6 +51,9 @@  select_memset_ifunc (void)
 	return __memset_a64fx;
     }
 
+  if (IS_ORYON1 (midr) && zva_size == 64)
+    return __memset_oryon1;
+
   if (IS_KUNPENG920 (midr))
     return __memset_kunpeng;
 
diff --git a/sysdeps/aarch64/multiarch/memset_oryon1.S b/sysdeps/aarch64/multiarch/memset_oryon1.S
new file mode 100644
index 0000000000..01db0b5241
--- /dev/null
+++ b/sysdeps/aarch64/multiarch/memset_oryon1.S
@@ -0,0 +1,176 @@ 
+/* Optimized memset for Qualcomm's oyron-1 core.
+   Copyright (C) 2018-2024 Free Software Foundation, Inc.
+   Copyright The GNU Toolchain Authors.
+
+   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>
+#include "memset-reg.h"
+
+/* Assumptions:
+ *
+ * ARMv8-a, AArch64, unaligned accesses
+ *
+ */
+
+ENTRY (__memset_oryon1)
+
+	PTR_ARG (0)
+	SIZE_ARG (2)
+
+	bfi	valw, valw, 8, 8
+	bfi	valw, valw, 16, 16
+	bfi	val, val, 32, 32
+
+	add	dstend, dstin, count
+
+	cmp	count, 96
+	b.hi	L(set_long)
+	cmp	count, 16
+	b.hs	L(set_medium)
+
+	/* Set 0..15 bytes.  */
+	tbz	count, 3, 1f
+	str	val, [dstin]
+	str	val, [dstend, -8]
+	ret
+
+	.p2align 3
+1:	tbz	count, 2, 2f
+	str	valw, [dstin]
+	str	valw, [dstend, -4]
+	ret
+2:	cbz	count, 3f
+	strb	valw, [dstin]
+	tbz	count, 1, 3f
+	strh	valw, [dstend, -2]
+3:	ret
+
+	.p2align 3
+	/* Set 16..96 bytes.  */
+L(set_medium):
+	stp	val, val, [dstin]
+	tbnz	count, 6, L(set96)
+	stp	val, val, [dstend, -16]
+	tbz	count, 5, 1f
+	stp	val, val, [dstin, 16]
+	stp	val, val, [dstend, -32]
+1:	ret
+
+	.p2align 6
+	/* Set 64..96 bytes.  Write 64 bytes from the start and
+	   32 bytes from the end.  */
+L(set96):
+	stp	val, val, [dstin, 16]
+	stp	val, val, [dstin, 32]
+	stp	val, val, [dstin, 48]
+	stp	val, val, [dstend, -32]
+	stp	val, val, [dstend, -16]
+	ret
+
+	.p2align 6
+L(set_long):
+	stp	val, val, [dstin]
+	bic	dst, dstin, 15
+	cmp	count, 256
+	ccmp	valw, 0, 0, cs
+	b.eq	L(try_zva)
+	cmp	count, #32768
+	b.hi	L(set_long_with_nontemp)
+	/* Small-size or non-zero memset does not use DC ZVA. */
+	sub	count, dstend, dst
+
+	/*
+	 * Adjust count and bias for loop. By subtracting extra 1 from count,
+	 * it is easy to use tbz instruction to check whether loop tailing
+	 * count is less than 33 bytes, so as to bypass 2 unnecessary stps.
+	 */
+	sub	count, count, 64+16+1
+
+1:	stp	val, val, [dst, 16]
+	stp	val, val, [dst, 32]
+	stp	val, val, [dst, 48]
+	stp	val, val, [dst, 64]!
+	subs	count, count, 64
+	b.hs	1b
+
+	tbz	count, 5, 1f	/* Remaining count is less than 33 bytes? */
+	stp	val, val, [dst, 16]
+	stp	val, val, [dst, 32]
+1:	stp	val, val, [dstend, -32]
+	stp	val, val, [dstend, -16]
+	ret
+
+L(set_long_with_nontemp):
+	/* Small-size or non-zero memset does not use DC ZVA. */
+	sub	count, dstend, dst
+
+	/*
+	 * Adjust count and bias for loop. By subtracting extra 1 from count,
+	 * it is easy to use tbz instruction to check whether loop tailing
+	 * count is less than 33 bytes, so as to bypass 2 unnecessary stps.
+	 */
+	sub	count, count, 64+16+1
+
+1:	stnp	val, val, [dst, 16]
+	stnp	val, val, [dst, 32]
+	stnp	val, val, [dst, 48]
+	stnp	val, val, [dst, 64]
+	add	dst, dst, #64
+	subs	count, count, 64
+	b.hs	1b
+
+	tbz	count, 5, 1f	/* Remaining count is less than 33 bytes? */
+	stnp	val, val, [dst, 16]
+	stnp	val, val, [dst, 32]
+1:	stnp	val, val, [dstend, -32]
+	stnp	val, val, [dstend, -16]
+	ret
+
+L(try_zva):
+	/* Write the first and last 64 byte aligned block using stp rather
+	   than using DC ZVA.  This is faster on some cores.
+	 */
+	.p2align 6
+L(zva_64):
+	stp	val, val, [dst, 16]
+	stp	val, val, [dst, 32]
+	stp	val, val, [dst, 48]
+	bic	dst, dst, 63
+	stp	val, val, [dst, 64]
+	stp	val, val, [dst, 64+16]
+	stp	val, val, [dst, 96]
+	stp	val, val, [dst, 96+16]
+	sub	count, dstend, dst	/* Count is now 128 too large.	*/
+	sub	count, count, 128+64+64	/* Adjust count and bias for loop.  */
+	add	dst, dst, 128
+1:	dc	zva, dst
+	add	dst, dst, 64
+	subs	count, count, 64
+	b.hi	1b
+	stp	val, val, [dst, 0]
+	stp	val, val, [dst, 16]
+	stp	val, val, [dst, 32]
+	stp	val, val, [dst, 48]
+
+	stp	val, val, [dstend, -64]
+	stp	val, val, [dstend, -64+16]
+	stp	val, val, [dstend, -32]
+	stp	val, val, [dstend, -16]
+	ret
+
+END (__memset_oryon1)