On Wed, 2020-07-29 at 15:08 -0700, Andre McCurdy wrote: > On Wed, Jul 29, 2020 at 6:46 AM Tanu Kaskinen <[email protected]> wrote: > > On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote: > > > 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? > > > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141716): https://lists.openembedded.org/g/openembedded-core/message/141716 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]] -=-=-=-=-=-=-=-=-=-=-=-
