Some clarification about AMD ifunc selection

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

Based on the repercussion this issue has raised in some communities
[1] [2], 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.

- 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 [3][4][5][6][7][8]. 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
forward.

[1] https://news.ycombinator.com/item?id=20908957
[2] https://www.realworldtech.com/forum/?threadid=187134&curpostid=187134
[3] https://www.sourceware.org/ml/libc-alpha/2015-12/msg00378.html
[4] https://www.sourceware.org/ml/libc-alpha/2016-02/msg00641.html
[5] https://www.sourceware.org/ml/libc-alpha/2016-03/msg00441.html
[6] https://sourceware.org/bugzilla/show_bug.cgi?id=20195
[7] https://sourceware.org/ml/libc-alpha/2018-07/msg00486.html
[8] https://sourceware.org/ml/libc-alpha/2018-12/msg00300.html