Re: Move powerpc ports pieces to libc.

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 27 Sep 2013, Adhemerval Zanella wrote:

> Thanks for the patch Joseph, I'm just thinking here the implication of this
> change for multilib support. Although I didn't receive any reply for my
> patches I still want to push them forward after Alan's LE patches. Currently

I'm not clear on the status of those LE patches.  There seem to have been 
a lot of different patches and patch series posted (some specifically LE, 
some more general ldbl-128ibm fixes), and at least some of the patches 
have been reviewed and approved, but none have been pushed.  I think we 
need those patches that have been approved (and don't depend on unapproved 
patches) to be pushed, and the remaining patches to be reposted, so that 
it's clear what's left to be reviewed or revised for the LE support.

> my set of patches onyl support the POWER variant and I don't think it
> makes sense to add the memory/string embedded optimizations on the
> POWER libc/libm.
> 
> So I open to suggestions, should I isolate the multilib to be POWER4+ only
> (by consolidating the implementations on sysdeps/powerpc/powerpc32/power4)?

We already have such restrictions for x86 (i386/i686/multiarch) and ARM 
(sysdeps/arm/armv7/multiarch), so that fits with existing practice.

Really the existing multi-arch support doesn't do a good job of optimizing 
for cases where only a subset of the multi-arch implementations are 
relevant.  If glibc is being built for a general-purpose GNU/Linux 
distribution, then you might want binaries with a wide range of 
architecture variant support (including both the POWER and 4xx functions 
in the Power Architecture case, for example).  But you might want to build 
with a given minimum architecture variant, and exclude all the function 
versions that, based on that minimum, are irrelevant (whether because some 
other version will always take priority, or because they require processor 
features that conflict with the minimum variant).  Or you might want to 
build with --disable-multi-arch, and then want the best version of the 
functions for the given minimum variant.

If on x86_64, say, glibc is built with a compiler that was configured 
--with-arch=corei7, any function variants that will never be used on a 
processor with all the features implied by -march=corei7 should not be 
compiled in at all, any runtime checks for support of a given variant 
that's guaranteed to work on such a processor should be eliminated, and 
any functions for which only one version is left should cease to be IFUNCs 
(and in such cases, the use of an optimized variant should not depend on 
multi-arch being enabled).  I don't know if there's a good way to define 
function variants to allow such optimizations (given the complicated mix 
of C and assembly involved in defining IFUNCs on different architectures); 
ARM does the optimizations to avoid building unnecessary variants and to 
avoid an IFUNC if the most optimized version is guaranteed to work, but 
even there none of the optimized versions are used at all for 
--disable-multi-arch.  And the maze of preprocessor conditionals in the 
various memcpy implementation files isn't really something that would be 
good to replicate many times for different sets of variants on different 
architectures.

In the absence of such a scheme by which you can declare things such as 
"POWER4+ conflicts with features required by 4xx functions, or implies 
some other version is always better than the 4xx version", and thereby 
automatically have the 4xx functions not built in, restricting the 
multi-arch support to POWER4+ seems reasonable.

-- 
Joseph S. Myers
joseph@codesourcery.com