Support NEON on mvebu arch

For Developers
21

Where exactly in menu_config would you place the "-mfpu=neon" flag? Does this also require the "-funsafe-math-optimizations" flag as well?

22

You can't change it in the menu_config ā€“ it will be overwritten.

You'll need to change it here:

Specifically:

CPU_SUBTYPE:=vfpv3 (change this to neon-vfpv3)

-funsafe-math-optimizations are only suggested if you want to do NEON auto-vectorization (employed at -O3 and above or with -ftree-vectorize).

Beware, that lua gets broken ā€“ and therefore, LuCI gets broken and will require: https://github.com/openwrt/luci/pull/1768 (however, the PR is not compatible with the recent switch to JS).

23

Would -O2 be helpful or just stick with -Os?

24

I fully understand the general defaults but I'd like to squeeze every safe bit out of this 3200ACM that I can to fully utilize it's power.

25

-O2 does help ā€“ in some cases I believe it even results in smaller binaries than -Os for ARM. The below should have been merged ā€“ but it seems that those with merging rights never bothered reviewing it.

Every use case is different, we all run different packages. Test -O3. If it causes problems or perceived loss of throughput, increased latency, or hangs ā€“ drop down to -O2.

26

Mvebu feels like the red headed stepchild of openwrt some times. :man_shrugging:

2 Likes
27

@ParanoidZoid the developers prefer the mailing list. However even then. they forget about several patches.

28

I used to do it in menuconfig with the option

CONFIG_EXTRA_OPTIMIZATION="-O3 -fno-caller-saves -fno-plt -mfpu=neon"

setting it to whatever, but have not used that option lately.

29

O2 helps quite a bit (not only on ARM) and is the default in pretty much all distros.

In general the best solution seems (unfortunately) to make as much noise as possible so if you want to push it feel free to reply in the PR and/or use the mailinglist. I personally have much less interest in OpenWrt nowdays and spend most of my time on other projects.

1 Like
30

Iā€™m now using full tickless, 1khz, -O2 neon-vfpv3. No compile errors, fast and stable.

31

I can't download any new packages:

root@OpenWrt:~# opkg list | grep veth
Package kmod-veth version 4.14.151-1 has no valid architecture, ignoring.

I 'm thinking there's something in menuconfig that I didn't enable or is it there a way like gentoo where it downloads and compiles on the fly?

32

If you're building your own firmware you also need to provide or include your own packages. On most cases OpenWrt's packages wont work as intended if you compile your own firmware with custom settings.

33

Capture of OpenWRT packages for mvebu arm
Capture of OpenWRT packages for mvebu arm1379Ɨ534 58.3 KB

I peaked at this and I see there's either neon OR vfpv3...not both. :thinking:

34

I found a thread that states neon implies vfpv3. Can someone confirm this?
https://linaro-toolchain.linaro.narkive.com/evimZrPi/what-mfpu-option-is-used-with-neon-vfpv3-and-vfpd32-flag

35

Yes, you only need to specify neon.

36

I don't mean to be a pest, but what about fastmult, thumb?

37

fast-math ? I did run neon with fast-math at some point, no issues seen. IEEE is already broken at the neon point so might as well go all in.

38

This may break things so you're on your own, it's not recommended to enforce those globally.

@anomeome
Telling the compiler that neon is available isn't the same thing as enforcing fast-math

39

I did not say that they were the same; and I meant -Ofast.

I said the code is no longer IEEE compliant with neon, so turning on -Ofast is not unreasonable. Depends on what one is chasing I guess, but as I stated I saw no issues with neon and -Ofast when I was playing around with some of the bits for AV transcoding running on a rango; iirc this was with GCC 7.