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

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

On Wed, 2020-07-29 at 15:08 -0700, Andre McCurdy wrote:
> On Wed, Jul 29, 2020 at 6:46 AM Tanu Kaskinen <tanuk@iki.fi> wrote:
> > On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote:
> > > On Sun, Jul 26, 2020 at 7:01 AM Khem Raj <raj.khem@gmail.com> wrote:
> > > > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <tanuk@iki.fi> wrote:
> > > > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote:
> > > > > > 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...
> > > > > 
> > > > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC.
> > > > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I
> > > > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is
> > > > > enabled in any case.
> > > > > 
> > > > > So, Meson seems pretty safe, although I guess it would be nice not to
> > > > > override the user's -mfpu setting. I think this isn't a big problem is
> > > > > practice, since runtime detection works.
> > > > > 
> > > > > I haven't tested with a compiler that truly can't build Neon code,
> > > > > because I don't know how to do that.
> > > 
> > > Presumably set a -mcpu=XXX to something which can never support NEON?
> > 
> > No success so far...
> > 
> > I tried CFLAGS_append = " -mcpu=cortex-a9+nosimd" in the pulseaudio
> > recipe, but Neon got still enabled. GCC warned that -march=armv7ve
> > conflicted with the chosen -mcpu (which makes sense, since "ve" in
> > "armv7ve" means "virtualization extensinons", and Cortex-A9 doesn't
> > have virtualization support, and all cores that have virtualization
> > support have mandatory Neon support).
> 
> Is that true? If so then the various armv7ve specific tuning files
> (tune-cortexa15.inc, etc) could all be simplified by removing the
> option to disable NEON support.

(Sorry for the delay in replying.)

I don't know if there's any official rule that cores with
virtualization must have Neon support (I would guess not). What I wrote
was only based on looking at this Wikipedia page, where every core with
virtualization also has Neon: 
https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures

Also, the GCC warning about conflicting -mcpu and -march turned out not
to be about armv7ve requiring Neon, I got the same warning also with
-march=armv7a and -mcpu=cortex-a9+nosimd. Maybe -mcpu and -march just
aren't supposed to be used together.

-- 
Tanu

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