On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <ta...@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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140950): https://lists.openembedded.org/g/openembedded-core/message/140950 Mute This Topic: https://lists.openembedded.org/mt/75658822/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
