This is the mail archive of the
mailing list for the glibc project.
Some clarification about AMD ifunc selection
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 10 Sep 2019 11:26:41 -0300
- Subject: Some clarification about AMD ifunc selection
Based on the repercussion this issue has raised in some communities
 , I would like to clarify some misconceptions points that are
brought in online discussions.
- glibc has moved to a community consensus with arch-maintainers having
a strong word regarding architecture specific bits. It does not mean
that arch-maintainer have a final word, but that other maintainers
usually trust their judgment regarding aspect like ABI issue,
performance optimizations, enablement for upcoming features, etc.
It also does not prevent any other maintainer, ever for other
architectures, to raise questions or even block some arch-specific
- Patch review is time-consuming for the arch-specific bits it means
the maintainer should be knowledgeable not only about the generic
implementation but also about architecture-specific parts. For an
extensive review for performance-related patches, it also means
the maintainer should have access to arch-specific manuals or actual
hardware along with a comprehensible test case to evaluate the
performance, which is not possible for most the cases. That's why
usually on glibc we rely on the patch submitter to provide such data.
- Performance evaluation is hard and glibc benchmark infrastructure
still requires improvements. It means it is not straightforward to
get the best permutation of optimized string routines for all possible
chips without some feedback about how these perform on real hardware
(BZ#16830 is an example). It gets even more complex when optimized
routines are added without actively being used (BZ#21572).
- Most of the x86 optimization work was done by Intel developers and
they were the ones driving both discussions about performance and
internal code organization. It does not prevent other developers to
ask for generic improvement for code organization (for instance the
work to move from assembly to C code for ifunc selection) or to ask
if the arch-specific implementation would indeed add real-world gains
(for instance on the AVX2 strcat/strncat submission).
- It also did not prevent other parties to push patches for x86 which
are AMD related . As Florian has expressed BZ#24979
we need more involvement and feedback from AMD for the performance work.
Said that I don't see that glibc 'discriminate' Zen or any other AMD
platform purposely. It is the fallout of 1. lack maintainer resources
from glibc community (both in manpower and infrastructure) and 2. more
Intel work than AMD towards some optimization decisions which biased
some design decision towards Intel. I can understand that for 2. Intel
should also be responsible for AMD performance to some extent and us
maintainer should have spotted this possible outcome in code reviewing.
So I am open to suggestion on how we can improve it, but my view
is we definitely need more engagement from AMD to fully move this