------- Comment From i...@de.ibm.com 2021-08-11 14:45 EDT-------
Oh, sorry, I forgot that you can't use the IBM BZ links. I indeed had the
following diffs in mind:
1.
#ifndef Z_IFUNC_ASM
local
#endif
-unsigned long (*(crc32_z_ifunc(void)))(unsigned long, const unsigned char FAR
*, z_size_t)
+unsigned long (*(crc32_z_ifunc(
+#ifdef __s390__
+unsigned long hwcap
+#else
+void
+#endif
+)))(unsigned long, const unsigned char FAR *, z_size_t)
{
#if _ARCH_PWR8==1
#if defined(__BUILTIN_CPU_SUPPORTS__)
2.
#endif
#endif /* _ARCH_PWR8 */
+#ifdef HAVE_S390X_VX
+ if (hwcap & HWCAP_S390_VX)
+ return s390_crc32_vx;
+#endif
+
/* return a function pointer for optimized arches here */
3.
static unsigned long ZEXPORT (*crc32_func)(unsigned long, const unsigned char
FAR *, z_size_t) = NULL;
if (!crc32_func)
- crc32_func = crc32_z_ifunc();
+ crc32_func = crc32_z_ifunc(
+#ifdef __s390__
+ getauxval(AT_HWCAP)
+#endif
+ );
return (*crc32_func)(crc, buf, len);
}
I think the latest debdiff still misses the second one (the getauxval()
call is still there):
++#if defined(__s390__) && defined(S390_CRC32_VX)
++ if (getauxval(AT_HWCAP) & HWCAP_S390_VX)
++ return s390_crc32_vx;
++#endif
A couple nits:
- changelog: it's dfltcc, not dltss (yeah, the name is super weird :-))
- "/* Work around a probable bug in glibc when invoking getauxval in the ifunc
*/" - I don't think it's actually a bug, since
https://sourceware.org/glibc/wiki/GNU_IFUNC says that:
When LD_BIND_NOW=1 or -Wl,z,now is in effect symbols must be immediately
resolved at startup. In cases where an external function call depends
needs to be made that may fail if such a call has not been initialized
yet (PLT-based relocation which is processed later). For example calling
strlen in an IFUNC resolver built with -Wl,z,now may lead to a segfault
because the PLT is not yet resolved. This may work on x86_64 where the
R_*_IRELATIVE relocations happen in DT_JMPREL after the DT_REL*
relocations, but that is no guarantee that it will work on AArch64,
PPC64, or other architectures that are slightly different. Such
fundamental limitations may be lifted at a future point.
What's surprising is rather that, given this paragraph, the code
nevertheless works and there doesn't seem to be an obvious glibc commit
that lifts this limitation.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1932010
Title:
[21.10 FEAT] zlib CRC32 optimization for s390x
Status in Ubuntu on IBM z Systems:
In Progress
Status in zlib package in Ubuntu:
In Progress
Bug description:
Use SIMD instructions to accelerate the zlib CRC32 implementation.
Business value: Performance improvement in database area
The zlib CRC32 optimization for IBM Z is currently being discussed for
inclusion into zlib-ng:
https://github.com/zlib-ng/zlib-ng/pull/912
The patch for zlib will be based on that.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
