* [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core
@ 2024-05-08 16:59 Andrew Pinski
2024-05-08 16:59 ` [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core Andrew Pinski
2024-05-14 7:35 ` [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core Florian Weimer
0 siblings, 2 replies; 12+ messages in thread
From: Andrew Pinski @ 2024-05-08 16:59 UTC (permalink / raw)
To: libc-alpha; +Cc: Andrew Pinski
Qualcomm's new core (oryon-1) has a different performance characteristic
than other cores. For memcpy, it is faster to use the GPRs to
do the copy for large sizes (2x faster). For even larger sizes,
it is better to use the nontemporal load/store instructions so
we don't pollute the L1/L2 caches.
For smaller sizes, the characteristic are very similar to
other cores.
I used the thunderx memcpy as a starting point and expanded from there.
Changes since v1:
* v2: Fix ordering in Makefile.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
---
sysdeps/aarch64/cpu-features.h | 6 +
sysdeps/aarch64/multiarch/Makefile | 1 +
sysdeps/aarch64/multiarch/ifunc-impl-list.c | 3 +
sysdeps/aarch64/multiarch/memcpy.c | 5 +
sysdeps/aarch64/multiarch/memcpy_oryon1.S | 301 ++++++++++++++++++++
5 files changed, 316 insertions(+)
create mode 100644 sysdeps/aarch64/multiarch/memcpy_oryon1.S
diff --git a/sysdeps/aarch64/cpu-features.h b/sysdeps/aarch64/cpu-features.h
index 31782b66f9..bc8d842238 100644
--- a/sysdeps/aarch64/cpu-features.h
+++ b/sysdeps/aarch64/cpu-features.h
@@ -1,6 +1,7 @@
/* Initialize CPU feature data. AArch64 version.
This file is part of the GNU C Library.
Copyright (C) 2017-2024 Free Software Foundation, Inc.
+ Copyright The GNU Toolchain Authors.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
@@ -56,6 +57,11 @@
#define IS_A64FX(midr) (MIDR_IMPLEMENTOR(midr) == 'F' \
&& MIDR_PARTNUM(midr) == 0x001)
+#define IS_ORYON1(midr) (MIDR_IMPLEMENTOR(midr) == 'Q' \
+ && (MIDR_PARTNUM(midr) == 0x001 \
+ || (MIDR_PARTNUM(midr) == 0x002 \
+ && MIDR_VARIANT(midr) == 0)))
+
struct cpu_features
{
uint64_t midr_el1;
diff --git a/sysdeps/aarch64/multiarch/Makefile b/sysdeps/aarch64/multiarch/Makefile
index e4720b7468..ef5ea9ab8c 100644
--- a/sysdeps/aarch64/multiarch/Makefile
+++ b/sysdeps/aarch64/multiarch/Makefile
@@ -5,6 +5,7 @@ sysdep_routines += \
memcpy_a64fx \
memcpy_generic \
memcpy_mops \
+ memcpy_oryon1 \
memcpy_sve \
memcpy_thunderx \
memcpy_thunderx2 \
diff --git a/sysdeps/aarch64/multiarch/ifunc-impl-list.c b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
index ecd0f87de6..65c56b9b41 100644
--- a/sysdeps/aarch64/multiarch/ifunc-impl-list.c
+++ b/sysdeps/aarch64/multiarch/ifunc-impl-list.c
@@ -1,5 +1,6 @@
/* Enumerate available IFUNC implementations of a function. 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
@@ -35,6 +36,7 @@ __libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array,
/* Support sysdeps/aarch64/multiarch/memcpy.c, memmove.c and memset.c. */
IFUNC_IMPL (i, name, memcpy,
IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_thunderx)
+ IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_oryon1)
IFUNC_IMPL_ADD (array, i, memcpy, !bti, __memcpy_thunderx2)
#if HAVE_AARCH64_SVE_ASM
IFUNC_IMPL_ADD (array, i, memcpy, sve && !bti, __memcpy_a64fx)
@@ -44,6 +46,7 @@ __libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array,
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_oryon1)
IFUNC_IMPL_ADD (array, i, memmove, !bti, __memmove_thunderx2)
#if HAVE_AARCH64_SVE_ASM
IFUNC_IMPL_ADD (array, i, memmove, sve && !bti, __memmove_a64fx)
diff --git a/sysdeps/aarch64/multiarch/memcpy.c b/sysdeps/aarch64/multiarch/memcpy.c
index ce53567dab..15c954778b 100644
--- a/sysdeps/aarch64/multiarch/memcpy.c
+++ b/sysdeps/aarch64/multiarch/memcpy.c
@@ -1,5 +1,6 @@
/* Multiple versions of memcpy. 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_memcpy) __memcpy_thunderx2 attribute_hidden;
extern __typeof (__redirect_memcpy) __memcpy_a64fx attribute_hidden;
extern __typeof (__redirect_memcpy) __memcpy_sve attribute_hidden;
extern __typeof (__redirect_memcpy) __memcpy_mops attribute_hidden;
+extern __typeof (__redirect_memcpy) __memcpy_oryon1 attribute_hidden;
static inline __typeof (__redirect_memcpy) *
select_memcpy_ifunc (void)
@@ -50,6 +52,9 @@ select_memcpy_ifunc (void)
return prefer_sve_ifuncs ? __memcpy_sve : __memcpy_generic;
}
+ if (IS_ORYON1 (midr))
+ return __memcpy_oryon1;
+
if (IS_THUNDERX (midr))
return __memcpy_thunderx;
diff --git a/sysdeps/aarch64/multiarch/memcpy_oryon1.S b/sysdeps/aarch64/multiarch/memcpy_oryon1.S
new file mode 100644
index 0000000000..21f9e1d4e0
--- /dev/null
+++ b/sysdeps/aarch64/multiarch/memcpy_oryon1.S
@@ -0,0 +1,301 @@
+/* A oryon-1 core Optimized memcpy implementation for AARCH64.
+ 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
+ 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 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
+
+/* Copies are split into 3 main cases: small copies of up to 16 bytes,
+ medium copies of 17..96 bytes which are fully unrolled. Large copies
+ of more than 96 bytes align the destination and use an unrolled loop
+ processing 64 bytes per iteration.
+ In order to share code with memmove, small and medium copies read all
+ data before writing, allowing any kind of overlap. So small, medium
+ and large backwards memmoves are handled by falling through into memcpy.
+ Overlapping large forward memmoves use a loop that copies backwards.
+*/
+
+ENTRY (__memmove_oryon1)
+
+ PTR_ARG (0)
+ PTR_ARG (1)
+ SIZE_ARG (2)
+
+ sub tmp1, dstin, src
+ cmp count, 96
+ ccmp tmp1, count, 2, hi
+ b.lo L(move_long)
+
+ /* Common case falls through into memcpy. */
+END (__memmove_oryon1)
+
+ENTRY (__memcpy_oryon1)
+
+ PTR_ARG (0)
+ PTR_ARG (1)
+ SIZE_ARG (2)
+
+ add srcend, src, count
+ add dstend, dstin, count
+ cmp count, 16
+ b.ls L(copy16)
+ cmp count, 96
+ b.hi L(copy_long)
+
+ /* Medium copies: 17..96 bytes. */
+ sub tmp1, count, 1
+ ldp A_l, A_h, [src]
+ tbnz tmp1, 6, L(copy96)
+ ldp D_l, D_h, [srcend, -16]
+ tbz tmp1, 5, 1f
+ ldp B_l, B_h, [src, 16]
+ ldp C_l, C_h, [srcend, -32]
+ stp B_l, B_h, [dstin, 16]
+ stp C_l, C_h, [dstend, -32]
+1:
+ stp A_l, A_h, [dstin]
+ stp D_l, D_h, [dstend, -16]
+ ret
+
+ .p2align 6
+ /* Small copies: 0..16 bytes. */
+L(copy16):
+ cmp count, 8
+ b.lo 1f
+ ldr A_l, [src]
+ ldr A_h, [srcend, -8]
+ str A_l, [dstin]
+ str A_h, [dstend, -8]
+ ret
+ .p2align 6
+1:
+ tbz count, 2, 1f
+ ldr A_lw, [src]
+ ldr A_hw, [srcend, -4]
+ 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. */
+1:
+ cbz count, 2f
+ lsr tmp1, count, 1
+ ldrb A_lw, [src]
+ ldrb A_hw, [srcend, -1]
+ ldrb B_lw, [src, tmp1]
+ strb A_lw, [dstin]
+ strb B_lw, [dstin, tmp1]
+ strb A_hw, [dstend, -1]
+2: ret
+
+ .p2align 6
+ /* Copy 64..96 bytes. Copy 64 bytes from the start and
+ 32 bytes from the end. */
+L(copy96):
+ ldp B_l, B_h, [src, 16]
+ ldp C_l, C_h, [src, 32]
+ ldp D_l, D_h, [src, 48]
+ ldp E_l, E_h, [srcend, -32]
+ ldp F_l, F_h, [srcend, -16]
+ stp A_l, A_h, [dstin]
+ stp B_l, B_h, [dstin, 16]
+ stp C_l, C_h, [dstin, 32]
+ stp D_l, D_h, [dstin, 48]
+ stp E_l, E_h, [dstend, -32]
+ stp F_l, F_h, [dstend, -16]
+ ret
+
+ /* Align DST to 16 byte alignment so that we don't cross cache line
+ boundaries on both loads and stores. There are at least 96 bytes
+ to copy, so copy 16 bytes unaligned and then align. The loop
+ copies 64 bytes per iteration and prefetches one iteration ahead. */
+
+ .p2align 6
+L(copy_long):
+
+ /* On oryon1 cores, large memcpy's are helped by using ldnp/stnp.
+ This loop is identical to the one below it but using ldnp/stnp
+ instructions. For loops that are less than 32768 bytes,
+ the ldnp/stnp does not help and slow the code down so we only
+ use the ldnp/stnp loop for the largest memcpys. */
+
+ cmp count, #32768
+ b.lo L(copy_long_without_nontemp)
+ and tmp1, dstin, 15
+ bic dst, dstin, 15
+ ldnp D_l, D_h, [src]
+ sub src, src, tmp1
+ add count, count, tmp1 /* Count is now 16 too large. */
+ ldnp A_l, A_h, [src, 16]
+ stnp D_l, D_h, [dstin]
+ ldnp B_l, B_h, [src, 32]
+ ldnp C_l, C_h, [src, 48]
+ ldnp D_l, D_h, [src, 64]
+ add src, src, #64
+ subs count, count, 128 + 16 /* Test and readjust count. */
+
+L(nontemp_loop64):
+ tbz src, #6, 1f
+1:
+ stnp A_l, A_h, [dst, 16]
+ ldnp A_l, A_h, [src, 16]
+ stnp B_l, B_h, [dst, 32]
+ ldnp B_l, B_h, [src, 32]
+ stnp C_l, C_h, [dst, 48]
+ ldnp C_l, C_h, [src, 48]
+ stnp D_l, D_h, [dst, 64]
+ ldnp D_l, D_h, [src, 64]
+ add src, src, #64
+ add dst, dst, #64
+ subs count, count, 64
+ b.hi L(nontemp_loop64)
+ b L(last64)
+
+L(copy_long_without_nontemp):
+
+ 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]!
+ 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
+
+ .p2align 6
+L(move_long):
+ cbz tmp1, 3f
+
+ add srcend, src, count
+ add dstend, dstin, count
+
+ /* Align dstend to 16 byte alignment so that we don't cross cache line
+ boundaries on both loads and stores. There are at least 96 bytes
+ to copy, so copy 16 bytes unaligned and then align. The loop
+ copies 64 bytes per iteration and prefetches one iteration ahead. */
+
+ and tmp1, dstend, 15
+ ldp D_l, D_h, [srcend, -16]
+ sub srcend, srcend, tmp1
+ sub count, count, tmp1
+ ldp A_l, A_h, [srcend, -16]
+ stp D_l, D_h, [dstend, -16]
+ ldp B_l, B_h, [srcend, -32]
+ ldp C_l, C_h, [srcend, -48]
+ ldp D_l, D_h, [srcend, -64]!
+ sub dstend, dstend, tmp1
+ subs count, count, 128
+ b.ls 2f
+
+ nop
+1:
+ stp A_l, A_h, [dstend, -16]
+ ldp A_l, A_h, [srcend, -16]
+ stp B_l, B_h, [dstend, -32]
+ ldp B_l, B_h, [srcend, -32]
+ stp C_l, C_h, [dstend, -48]
+ ldp C_l, C_h, [srcend, -48]
+ stp D_l, D_h, [dstend, -64]!
+ ldp D_l, D_h, [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:
+ ldp G_l, G_h, [src, 48]
+ stp A_l, A_h, [dstend, -16]
+ ldp A_l, A_h, [src, 32]
+ stp B_l, B_h, [dstend, -32]
+ ldp B_l, B_h, [src, 16]
+ stp C_l, C_h, [dstend, -48]
+ ldp C_l, C_h, [src]
+ stp D_l, D_h, [dstend, -64]
+ stp G_l, G_h, [dstin, 48]
+ stp A_l, A_h, [dstin, 32]
+ stp B_l, B_h, [dstin, 16]
+ stp C_l, C_h, [dstin]
+3: ret
+
+END (__memcpy_oryon1)
--
2.43.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-08 16:59 [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core Andrew Pinski
@ 2024-05-08 16:59 ` Andrew Pinski
2024-05-13 13:48 ` Florian Weimer
2024-05-14 7:32 ` Florian Weimer
2024-05-14 7:35 ` [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core Florian Weimer
1 sibling, 2 replies; 12+ messages in thread
From: Andrew Pinski @ 2024-05-08 16:59 UTC (permalink / raw)
To: libc-alpha; +Cc: 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.
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
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)
--
2.43.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-08 16:59 ` [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core Andrew Pinski
@ 2024-05-13 13:48 ` Florian Weimer
2024-05-14 6:19 ` Andrew Pinski (QUIC)
2024-05-14 7:32 ` Florian Weimer
1 sibling, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2024-05-13 13:48 UTC (permalink / raw)
To: Andrew Pinski; +Cc: libc-alpha
* 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-13 13:48 ` Florian Weimer
@ 2024-05-14 6:19 ` Andrew Pinski (QUIC)
2024-05-14 7:37 ` Florian Weimer
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Pinski (QUIC) @ 2024-05-14 6:19 UTC (permalink / raw)
To: Florian Weimer, Andrew Pinski (QUIC); +Cc: libc-alpha
> -----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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-08 16:59 ` [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core Andrew Pinski
2024-05-13 13:48 ` Florian Weimer
@ 2024-05-14 7:32 ` Florian Weimer
2024-05-14 7:40 ` Andrew Pinski (QUIC)
1 sibling, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2024-05-14 7:32 UTC (permalink / raw)
To: Andrew Pinski; +Cc: libc-alpha
* 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core
2024-05-08 16:59 [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core Andrew Pinski
2024-05-08 16:59 ` [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core Andrew Pinski
@ 2024-05-14 7:35 ` Florian Weimer
1 sibling, 0 replies; 12+ messages in thread
From: Florian Weimer @ 2024-05-14 7:35 UTC (permalink / raw)
To: Andrew Pinski; +Cc: libc-alpha
* Andrew Pinski:
> + /* On oryon1 cores, large memcpy's are helped by using ldnp/stnp.
> + This loop is identical to the one below it but using ldnp/stnp
> + instructions. For loops that are less than 32768 bytes,
> + the ldnp/stnp does not help and slow the code down so we only
> + use the ldnp/stnp loop for the largest memcpys. */
Grammar nit: “the ldnp/stnp does not help and slow the code” uses
singular “does” and plural “slow”.
Thanks,
Florian
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-14 6:19 ` Andrew Pinski (QUIC)
@ 2024-05-14 7:37 ` Florian Weimer
2024-05-14 7:47 ` Andrew Pinski (QUIC)
0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2024-05-14 7:37 UTC (permalink / raw)
To: Andrew Pinski (QUIC); +Cc: libc-alpha
* 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-14 7:32 ` Florian Weimer
@ 2024-05-14 7:40 ` Andrew Pinski (QUIC)
2024-05-22 23:01 ` Andrew Pinski (QUIC)
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Pinski (QUIC) @ 2024-05-14 7:40 UTC (permalink / raw)
To: Florian Weimer, Andrew Pinski (QUIC); +Cc: libc-alpha
> -----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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-14 7:37 ` Florian Weimer
@ 2024-05-14 7:47 ` Andrew Pinski (QUIC)
2024-05-14 9:10 ` Florian Weimer
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Pinski (QUIC) @ 2024-05-14 7:47 UTC (permalink / raw)
To: Florian Weimer, Andrew Pinski (QUIC); +Cc: libc-alpha
> -----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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-14 7:47 ` Andrew Pinski (QUIC)
@ 2024-05-14 9:10 ` Florian Weimer
0 siblings, 0 replies; 12+ messages in thread
From: Florian Weimer @ 2024-05-14 9:10 UTC (permalink / raw)
To: Andrew Pinski (QUIC); +Cc: libc-alpha
* 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-14 7:40 ` Andrew Pinski (QUIC)
@ 2024-05-22 23:01 ` Andrew Pinski (QUIC)
2024-05-23 13:08 ` Adhemerval Zanella Netto
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Pinski (QUIC) @ 2024-05-22 23:01 UTC (permalink / raw)
To: Andrew Pinski (QUIC), Florian Weimer; +Cc: libc-alpha
> -----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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core
2024-05-22 23:01 ` Andrew Pinski (QUIC)
@ 2024-05-23 13:08 ` Adhemerval Zanella Netto
0 siblings, 0 replies; 12+ messages in thread
From: Adhemerval Zanella Netto @ 2024-05-23 13:08 UTC (permalink / raw)
To: Andrew Pinski (QUIC), Florian Weimer; +Cc: libc-alpha
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-05-23 13:08 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-08 16:59 [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core Andrew Pinski
2024-05-08 16:59 ` [PATCH v2 2/2] Aarch64: Add new memset for Qualcomm's 0ryon-1 core Andrew Pinski
2024-05-13 13:48 ` Florian Weimer
2024-05-14 6:19 ` Andrew Pinski (QUIC)
2024-05-14 7:37 ` Florian Weimer
2024-05-14 7:47 ` Andrew Pinski (QUIC)
2024-05-14 9:10 ` Florian Weimer
2024-05-14 7:32 ` Florian Weimer
2024-05-14 7:40 ` Andrew Pinski (QUIC)
2024-05-22 23:01 ` Andrew Pinski (QUIC)
2024-05-23 13:08 ` Adhemerval Zanella Netto
2024-05-14 7:35 ` [PATCH v2 1/2] Aarch64: Add memcpy for qualcomm's oryon-1 core Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).