On Sun, Jul 26, 2020 at 7:01 AM Khem Raj <[email protected]> wrote: > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <[email protected]> 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 <[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.
Presumably set a -mcpu=XXX to something which can never support NEON? > Right. Cpu implementations without neon do exist > But they are perhaps rare enough and may not use the package too so chances > are slim that we encounter this issue So what's the conclusion? That CPU's without NEON are so rare that OE doesn't need to care about them?
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141015): https://lists.openembedded.org/g/openembedded-core/message/141015 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]] -=-=-=-=-=-=-=-=-=-=-=-
