[Buildroot] [PATCH] package/zlib-ng: Backport patch to fix linking on powerpc

[Joel Stanley]

On Tue, 5 Apr 2022 at 19:55, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
>
> Arnout, All,
>
> On 2022-04-04 22:17 +0200, Arnout Vandecappelle spake thusly:
> > On 04/04/2022 11:12, Joel Stanley wrote:
> > >Commit 192dfc68c0e4 ("package/zlib-ng: fix build on powerpc") turned the
> >  Peter just backported this one to 2022.02.x...
> > >Power8 optimisations off to fix a build issue. Instead apply a patch
> > >from the develop branch upstream to fix the issue.
> > >
> > >This patch is not yet in a released version of zlib-ng.
> > >
> > >Signed-off-by: Joel Stanley <joel at jms.id.au>
> >  Applied to master, thanks.
>
> Err... Why would we enable the POWER8 optimisations when the target is
> not a POWER8 ?
>
> Backporting the patch seems correct, but the enabling/disabling the
> optinisations should have stayed, I believe...

Taking a look at the cmake configuration, there's dozens of options
that provide optimisations. It looks like it does detection of
features:

    elseif(BASEARCH_PPC_FOUND)
        # Common arch detection code
        if(WITH_ALTIVEC)
            check_ppc_intrinsics()
        endif()
        if(WITH_POWER8)
            check_power8_intrinsics()
        endif()
        if(HAVE_VMX OR HAVE_POWER8_INTRIN)
            list(APPEND ZLIB_ARCH_HDRS ${ARCHDIR}/power_features.h)
            list(APPEND ZLIB_ARCH_SRCS ${ARCHDIR}/power_features.c)
...

        if(WITH_POWER8)
            if(HAVE_POWER8_INTRIN)
                add_definitions(-DPOWER8)
                add_definitions(-DPOWER_FEATURES)
                add_definitions(-DPOWER8_VSX_ADLER32)
                add_definitions(-DPOWER8_VSX_CHUNKSET)
                add_definitions(-DPOWER8_VSX_SLIDEHASH)
                set(POWER8_SRCS ${ARCHDIR}/adler32_power8.c
${ARCHDIR}/chunkset_power8.c ${ARCHDIR}/slide_hash_power8.c)
                if("${ARCH}" MATCHES "powerpc64(le)?")
                    add_definitions(-DPOWER8_VSX_CRC32)
                    list(APPEND POWER8_SRCS ${ARCHDIR}/crc32_power8.c)
                endif()
                list(APPEND ZLIB_ARCH_SRCS ${POWER8_SRCS})
                set_property(SOURCE ${POWER8_SRCS} PROPERTY
COMPILE_FLAGS "${POWER8FLAG} ${NOLTOFLAG}")
            else()
                set(WITH_POWER8 OFF)
            endif()


The check looks like this.

check_power8_intrinsics() {
    # Check whether features needed by POWER optimisations are available
    cat > $test.c << EOF
#include <sys/auxv.h>
int main() { return (getauxval(AT_HWCAP2) & PPC_FEATURE2_ARCH_2_07); }
EOF
    if test $buildpower8 -eq 1 && try $CC -c $CFLAGS -mcpu=power8 $test.c; then
        HAVE_POWER8_INTRIN=1
        echo "Check whether POWER8 instructions are available ...
Yes." | tee -a configure.log
    else
        HAVE_POWER8_INTRIN=0
        echo "Check whether POWER8 instructions are available ... No."
| tee -a configure.log
    fi
}

So as long as your compiler defines the PPC_FEATURE2_ARCH_2_07 in
auxv.h, and supports -mcpu=power8, it will build the code. The
application then does runtime checking of auxv to decide if the
optimisations should be used.

Setting WITH_POWER8=OFF on the command line will skip the checks, and
not build in the optimisations.

WITH_POWER8=ON has no effect as it's the default and the cmake logic
will turn it off if it detects the platform isn't capable.

>From what I can see, there's a small binary size reduction to be had
by forcing Power8 off if your toolchain is power8 capable but you know
your platform isn't. I think this is the case for GCC built for
ppc64(le) but targeting a different CPU.

I suggest we let the zlib-ng build system do its thing to ease the
maintenance burden of keeping the flags up to date.

I also welcome someone double checking my analysis, as I may have
misunderstood something.

Cheers,

Joel