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 <[email protected]> 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. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140951): https://lists.openembedded.org/g/openembedded-core/message/140951 Mute This Topic: https://lists.openembedded.org/mt/75658822/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
