This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Move powerpc ports pieces to libc.
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org, Alan Modra <amodra at gmail dot com>
- Date: Mon, 30 Sep 2013 14:08:13 -0500
- Subject: Re: Move powerpc ports pieces to libc.
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1309261728050 dot 13950 at digraph dot polyomino dot org dot uk> <52458373 dot 4030301 at linux dot vnet dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1309271531060 dot 7561 at digraph dot polyomino dot org dot uk>
- Reply-to: munroesj at us 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.
>