Please address questions and comments to Steve Munroe <munroesj@us.ibm.com>.

Download

  • glibc-powerpc-cpu-addon-v0.06.tgz
  • glibc-powerpc-cpu-addon-v0.05.tgz
  • glibc-powerpc-cpu-addon-v0.04.tgz
  • glibc-powerpc-cpu-addon-v0.03.tgz
  • glibc-powerpc-cpu-addon-v0.02.tgz
  • glibc-powerpc-cpu-addon-v0.01.tgz
  • What is powerpc-cpu:

    The glibc powerpc-cpu add-on is a source add-on to the GNU C Library (glibc) that adds CPU specific optimizations. It works with the new --with-cpu= configure option to enable gcc -mcpu= based optimizations and hand tuned assembler overrides of existing glibc functions. These optimizations are supported on a cpu_type basis (7450, 970, power4, power5, ...), whereas the glibc mainline configure only allows for the two generic ABIs powerpc32 and powerpc64.

    The implementation in glibc mainline leaves a lot of performance on the table because that source must be safe and reasonable to run on any processor for that architecture. This is especially problematic for powerpc32 which has a long history and is supported on a wide variety of chip implementations.  For example, there is a real concern that a highly optimized version of memcpy for the power5 may not perform well on the G4 or older chips like the 603. But a version of memcmp or memcpy can show significant gains by hand optimizing for the specific micro-architecture. For example, hand-tuned 32-bit versions of memcpy and memcmp show 50-75% improvement on the 970 over the generic implementation from glibc mainline. The goal of powerpc-cpu is to allow any powerpc chip variant to <cpu_type> specific otimizations.

    As such, the powerpc-cpu add-on is not intended to add features to the glibc API, but rather to provide alternative implementations to existing glibc functions. At this stage powerpc-cpu is the first to use the --with-cpu mechanism, which is new to glibc and needs some testing mileage. The intent is that powerpc-cpu will eventually be merged back into the glibc-cvs tree (perhaps under ports), but for now I will maintain the tar file.

    How do I use powerpc-cpu:

    This add-on directs glibc to be built with additional platform/cpu specific optimizations. Specifying --with-cpu=<cpu_type> on the glibc configure implicitly inserts the -mcpu=<cpu_type> option for gcc commands in the glibc make. It also inserts <cpu_type> specific directories from the powerpc-cpu add-on into the source search path for glibc builds. See "
    libc add-ons changes"
      and the GLIBC ports README

    Simply untar this file into the your working glibc 2.4 or glibc 2.5 source directory. The powerpc-cpu add-on must be explicitly enabled as an add-on with a specific <cpu_type> at the configure step. For example:

    $source/configure \
            --build=powerpc-linux \
            --host=powerpc-linux \
            --target=powerpc-linux \
            --srcdir=${source} \
            --with-tls \
            --with-__thread \
            --enable-add-ons=powerpc-cpu,nptl \
            --with-cpu=970 \
            --enable-shared \
            --without-cvs \
            --with-headers=${kernelheaders} \
            --prefix=${targetdir}


    The glibc configure/make systems will implicitly add -mcpu=970 to all gcc compile (of .c code) steps and inserts the ./powerpc-cpu/sysdeps/powerpc/powerpc32/970/ and
    ./powerpc-cpu/sysdeps/unix/sysv/linux/powerpc/powerpc32/970/ directories and subdirectories into the search list for the build.

    This release (V0.04) supports the following <cpu_types>:

     

    Ppc970

    Power4

    Power5

    Power5+

    Power6

    Power6x

     

    We include power4/5 optimized memcpy/memcmp/memset implementations and examples of exploiting 64-bit instructions for 32-bit mode (llrint, llround).

    One issue with <cpu_type> specific optimizations is the ability to use new instructions that give some advantage on the new chip (family) but may not be available (sigill) on older chips. GCC defaults to -mcpu=powerpc which generates code that is safe for any pure PowerPC (starting with the 603). Specifying -mcpu-power5 allows gcc to use the POWER5 ISA (including new instructions). So obviously building glibc with --with-cpu=power5 is not a good idea unless you plan to only install that glibc on POWER5 systems.

    If you need to build generic distributions (i.e., Linux supporting several <cpu_types>) you can leverage the dl_procinfo support built into glibc. This mechanism allows for multiple versions of the core libraries (libc, libm, librt, libpthread, libpthread_db) to be stored in hardware/platform specific subdirectories under /lib[64]. Then at runtime the loader (ld.so) will use the Aux Vector AT_HWCAP and AT_PLATFORM information to select which subdirectory to search first. For example; this allows for power4, power5, etc. optimized binaries to installed on a system and the loader will load the appropriate optimized library (-mcpu=power5, /lib[64]/power5/libc.so) if available or the default (-mcpu=powerpc, /lib[64]/libacl.so ) library if not. See "[RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc, revised" for details.

    Extending powerpc-cpu:

    You can add your own <cpu_type> specific optimizations to this framework. To add a new cpu_type simply mkdir the new <cpu_type> directories into theexisting powerpc-cpu add-on file structure: For example:

    mkdir ${source}/powerpc-cpu/sysdeps/powerpc/powerpc32/${cpu_type}
    mkdir ${source}/powerpc-cpu/sysdeps/powerpc/powerpc32/${cpu_type}/fpu
    mkdir ${source}/powerpc-cpu/sysdeps/unix/sysv/linux//powerpc/powerpc32/${cpu_type}
    mkdir ${source}/powerpc-cpu/sysdeps/unix/sysv/linux//powerpc/powerpc32/${cpu_type}/fpu


    And 64-bit platform you will want to add:

    mkdir ${source}/powerpc-cpu/sysdeps/powerpc/powerpc64/${cpu_type}
    mkdir ${source}/powerpc-cpu/sysdeps/powerpc/powerpc64/${cpu_type}/fpu
    mkdir ${source}/powerpc-cpu/sysdeps/unix/sysv/linux/powerpc/powerpc64/${cpu_type}
    mkdir ${source}/powerpc-cpu/sysdeps/unix/sysv/linux/powerpc/powerpc64/${cpu_type}/fpu


    This will allow glibc configure to use the --with-cpu= option even if you don't have any hand optimized overrides. To override existing implementations from glibc mainline just create your source with the same name (a .S file can override a .c file) in the appropriate directory. For example if you have a hand-optimized implementation of memset for the8540 chip, copy your memset.S file into:

    ${source}/powerpc-cpu/sysdeps/powerpc/powerpc32/8540/memset.S.


    For fpu specific optimizations use the ./8450/fpu subdirectory. For OS/Linux specific optimizations use the sysdeps/unix/sysv/linux/powerpc/powerpc32 directories . You can put any number of 8540 specific optimizations in these directories as long as the file names match existing files from glibc mainline. See the README and gcc docs for more detailed description of naming and adding new cpu_types.

    I welcome contributions of additional <cpu_type> specific optimizations for PowerPC, including powerpc32 on 64-bit, and Altivec/VMX specific optimization to powerpc_cpu. As the intent is to contribute powerpc_cpu back to the GLIBC project we need to play by GLIBC rules. Contributors should have a FSF copyright assignment on file and attest to the origins of any code that is offered. All source code should include the FSF copyright header.

    The --with-cpu is not powerpc specific and can be applied to any platforms where gcc supports the --mcpu= option. Any one who is interested can use powerpc-cpu as an example to create their own cpu specific add-ons for their platform.