[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Does ARMEL toolchain include NEON support?



On Wed, Feb 27, 2019 at 2:59 PM Vagrant Cascadian <vagrant@debian.org> wrote:
>
> On 2019-02-27, Jeffrey Walton wrote:
> > I'm investigating a failed build for ARMEL. I don't have access to the
> > build machine so I have to study the logs or ask our package
> > maintainer to run commands for us.
> >
> > The build log is at
> > https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B&suite=experimental
> > (package) and https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B&arch=armel&ver=8.1.0-1&stamp=1551251751&raw=0
> > (ARMEL).
> >
> > We have tried to use -mfpu=neon and -mfloat-abi=softfp or
> > -mfloat-abi=hard for the NEON specific files but both produce compile
> > failures. "NEON specific files" are ones with the name *_simd.cpp,
> > like aria_simd.cpp.
> >
> > I test the build locally with about 6 ARM dev-boards and have not
> > encountered the problem. However, all of the dev-board are hard float
> > machines.
> >
> > My question is, is it possible to use the NEON unit when building with
> > ARMEL? If so, then how do we do it?
>
> My understanding is that neither armhf nor armel assume the presence of
> NEON; it's optional, and code must not be built forcing the use of NEON
> on those architectures.

Got it.

> NEON support needs to be detected at runtime, and the code handle if
> NEON is not present.

Right, that's what we do. At runtime we switch to NEON if available.
Confer (https://github.com/weidai11/cryptopp/blob/master/aria.cpp#L179):

#if CRYPTOPP_ARM_NEON_AVAILABLE
    if (HasNEON())
    {
        ARIA_UncheckedSetKey_Schedule_NEON(rk, m_w, keylen);
    }
    else
#endif
    {
        // C/C++ implementation
        ...
    }

The problem is, we cannot compile modules with NEON support. It is
like the compiler is missing NEON support.

The architectural difference seems to be, some other projects use GAS,
and provide the  ASM in *.s file. We use C/C++ intrinsics in a *.c or
*.cpp file. (This allows us to support more platforms using a single
code base, like Android, Linux, iOS, Windows Mobile and Windows Phone.
The downside is, we are usually a tad bit slower than ASM).

Jeff


Reply to: