Re: Move powerpc ports pieces to libc.

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Fri, 2013-09-27 at 15:58 +0000, Joseph S. Myers wrote:
> 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).  

If you are suggesting that we would have a single distro spanning lowest
32-bit embedded 4xx to top of the top of the line 795 256-core Power7+,
I don't think that is a reasonable assumptions.

1) Most embedded chips are 32-not only and all server chips are 64-bit.
2) The trend in Enterprise distros to go 64-bit and deprecate 32-bit
runtime support.
3) There are Embedded specific booke extensions that conflict in op-code
space with Server features like VSX. So it will be be difficult to build
a single toolchain that build all the sub-arches in one package.
4) The embedded environments are storage constrained and so are not
going to support multi-arch/multilib any way.

There is a reason why the PowerISA is organized a base plus embedded OR
Server extensions (AKA Categories).


> 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.
> 

For IFUNC multi-arch I think we want to build with a list of sub-arches
and not every implementation in the source tree. 

> 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.
>