Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

["Tanu Kaskinen" <tanuk@iki.fi>]

On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote:
> > Hi!
> > 
> > If a recipe provides NEON optimizations, should those be explicitly
> > disabled when "neon" is not in TUNE_FEATUERS, even if the software is
> > able to detect NEON availability at runtime?
> > 
> > I'm currently converting the pulseaudio recipe from Autotools to Meson,
> > and the old Autotools build system supports disabling NEON
> > optimizations but the Meson build system doesn't. So I'm wondering if I
> > should add the missing feature to the Meson build system, or just let
> > the runtime detection do its work.
> > 
> > Is there ever need for disabling NEON optimizations if the CPU
> > indicates NEON support? I guess it could be useful for testing the "no
> > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES
> > doesn't remove NEON support from the qemuarm machine), but otherwise it
> > seems unnecessary, unless there are CPUs that advertise NEON support
> > but don't actually support it.
> > 
> 
> I think the issue will result in a compiler error perhaps when neon is
> disabled via
> compiler command line which would be the case when neon is not in TUNE_FEATURES
> the compiler might warn or error out when it finds neon instructions
> being compiled via inline
> assembly.  you just can try passing something like -mfpu=vfpv3d16 or
> some such and see if
> compiler/assembler complains during build, if not then perhaps its fine.

If the last -mfpu is something else than neon, then including
arm_neon.h will succeed but compiling neon code will fail.

I did some experiments, and what I found was that when I remove neon
from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very
early in the compiler command line. PulseAudio adds -mfpu=neon to
CFLAGS when building neon code, and the last -mfpu wins, so the neon
code gets built without errors.

The configure check in PulseAudio only checks that the compiler accepts
-mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any
actual neon code. This means that if the user adds -mfpu=vfp (or other
non-neon) to CFLAGS rather than CC, configure will pass but building
will fail. Is this something to guard against? A default qemuarm build
doesn't do this, so I don't know if this ever happens in OE.

I don't know yet how Meson behaves, I'll continue testing...

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk