Page MenuHomePhabricator
Create Task
Maniphest T8709

-Dnative-arch-optimization assumes all arm CPUs have neon instruction set
Closed, WontfixPublic
Actions

Description

In efl there is a meson configure option for native-arch-optimization which does all kind of default optimizations depending on CPU you have. For arm, it adds few things seen in here:
https://git.enlightenment.org/core/efl.git/tree/meson.build?h=v1.24.1#n165

However not all arm CPUs include neon instruction set, such as tegra20. A bug was reported originally here:
https://bugs.gentoo.org/722552

I saw there were a couple of open tickets regarding arm-neon affairs, but nothing related to native-arch-optimization or meson.

juippis created this task.May 11 2020, 11:10 PM
ProhtMeyhet edited projects, added Restricted Project; removed efl (efl-1.24).May 11 2020, 11:42 PM
ProhtMeyhet added a subscriber: bu5hm4n.
ProhtMeyhet triaged this task as High priority.May 11 2020, 11:47 PM
bu5hm4n added subscribers: Hermet, raster.May 25 2020, 1:48 AM

I think we should add here @raster and @Hermet

As far as i read the gentoo issue, this is about runtime detection of neon availability, (or in general all arch-optimization). Or Am i missing something ?

raster added a comment.May 25 2020, 5:02 AM

Realistically... the only SoC that did armv7 that didn't do neon were the early tegras - they fixed that later. So ... just disable these optimizations if you have this corner case. 99.9% of armv7 socs do neon. it is a build option and it can be swizzled... should we hurt the performance of 99.9% of situations for the 0.1 that that don't? and there is an option it off for this 0.1% ... :) aarch64 fixed this by making neon required of course (well in practice)... :)

juippis added a comment.May 27 2020, 10:14 PM

As far as i read the gentoo issue, this is about runtime detection of neon availability, (or in general all arch-optimization). Or Am i missing something ?

To my understanding it breaks building efl on arm boards with no neon support.

Realistically... the only SoC that did armv7 that didn't do neon were the early tegras - they fixed that later. So ... just disable these optimizations if you have this corner case. 99.9% of armv7 socs do neon. it is a build option and it can be swizzled... should we hurt the performance of 99.9% of situations for the 0.1 that that don't? and there is an option it off for this 0.1% ... :) aarch64 fixed this by making neon required of course (well in practice)... :)

Yes it would be possible to check exactly what arm chipset is being used, and disable 'native-arch-optimization' if neon is not supported with it. I'm not familiar with arm boards, but if the numbers are really 99,9 % - 0,01 % I agree you shouldn't spend time on this.

raster added a comment.May 28 2020, 12:56 AM

they are rare. super rare. it's an aberration to have a SoC that does not support neon. to the point where it's so painful that for armv8 (64bit) neon became mandated to stop the need to account for that 0.1% of devices - much less effort for devs, code, build systems etc.

and as i said... for those 0.1% there is a solution at build time. :)

ProhtMeyhet closed this task as Wontfix.Jun 2 2020, 4:32 AM
ProhtMeyhet assigned this task to raster.
ProhtMeyhet added a subscriber: ProhtMeyhet.

From the gentoo bug report:

I would say -cpu_flags_neon, but gentoo gets this wrong too in the armv7 profile. I have it masked in my local profile. There is also USE=-neon. I think relying on the user having these set correctly is not unreasonable.

Please reopen if you find a solution of detecting neon.