use neon on armv7

[kali]

enable neon support on armv7 platforms.

An alternative was to disable neon code altogether, but part of the code already assumes it's there. I know most devices will have it, but I'm not sure whether or there exist neon-less armv7 around. As far as I can tell, all phones and mainstream stuff should have it.

see also #312

[briansmith]

Thanks for the PR.

Is your goal to fix the iOS build? If not, what is the goal of the PR?

It is the case that NEON is typically available on the most common ARMv7 platforms, particularly Android and iOS phones. But, in some cases we avoid using NEON instructions because the chip's NEON support is broken; see crypto/cpu-arm-linux.c for details. So, depending on your goal, this might be the best way of doing things, or there might be a better way.

[kali]

I'm mostly interested in getting hyper/rustls/ring work on phones, both ios and android. I don't need extraordinary performance, so a non-neon build is perfectly ok for my need.

I may be able to find a few hours to spend on this here and there, but I'll need some guidance: I now understand that using neon without runtime check is relatively dangerous and not mergeable as is (even if I could use it in my specific use-case). Should I try to make the arm build NEON-less as a first step instead ? I tried defining OPENSSL_NO_ASM on arm, it did not fix all the compilation issue, but it may be safer to start that way.

[briansmith]

I'm mostly interested in getting hyper/rustls/ring work on phones, both ios and android. I don't need extraordinary performance, so a non-neon build is perfectly ok for my need.

OK. ring is already building successfully on Android, right? So, are you trying to fix the iOS build now? Or, are there problems on Android too?

Should I try to make the arm build NEON-less as a first step instead?

If you are just trying to get iOS to work, then I'll accept pretty much any reasonable patch to fix the iOS build. The best patch would enable NEON for all iOS builds, but if we need to disable some asm code for iOS temporarily, I'm happy to do that; we can then file a follow-up issue to re-enable any assembly-language optimizations we temporarily disable.

I tried defining OPENSSL_NO_ASM on arm, it did not fix all the compilation issue, but it may be safer to start that way.

The OPENSSL_NO_ASM stuff is left over from BoringSSL and isn't supported in ring.

[kali]

ok. No, nothing problematic on android so far. I built ring successfully with arm and armv7 targets. I will try x86 soon, because I need the simulator/emulator, but I don't expect neon to show up there.

So yeah, I only have issues with iOS. My understanding is that all armv7 iOS have NEON, and I could not find reports of iOS devices with a broken one, so this patch may actually do the right thing in the end :)

[coveralls]

Coverage remained the same at 91.126% when pulling 074d84e on kali:master into 4102ae7 on briansmith:master.

[coveralls]

Coverage remained the same at 91.126% when pulling 074d84e on kali:master into 4102ae7 on briansmith:master.

[briansmith]

ok. No, nothing problematic on android so far. I built ring successfully with arm and armv7 targets. I will try x86 soon, because I need the simulator/emulator, but I don't expect neon to show up there.

So yeah, I only have issues with iOS. My understanding is that all armv7 iOS have NEON, and I could not find reports of iOS devices with a broken one, so this patch may actually do the right thing in the end :)

I believe that we want to support Android on ARMv7 devices without (working) NEON. If your changes enable iOS builds to succeed, thencan we change the patch to add -arch $(TARGET_ARCH_BASE) -mfpu=neon only when the target ARCH is ARMv7 and the target OS is iOS?

[kali]

The change I'm proposing is inside a ifeq ($(TARGET_SYS),ios) section so I think it is already exactly what you describe. And it does fix the iOS builds for armv7 (and armv7s). Other builds I could check look non affected, as we should expect.

[briansmith]

The change I'm proposing is inside a ifeq ($(TARGET_SYS),ios)

Ah, got it. Thanks! That wasn't in the diff context I saw and I didn't realize we'd already landed some ios changes.

[briansmith]

Thanks a lot. This landed in master as 4efb6f5.

[briansmith]

Are you able to run the tests on iOS ARMv7 too? Does everything pass?

[kali]

I don't think there is any easy way to run the tests on iOS. Maybe with a jailbroken device, or by re-packaging all the tests in a ad-hoc app.

[briansmith]

OK, thanks!

[kali]

Thanks for merging. If I think of, or end up doing something smart for the tests, I'll make a PR.

[briansmith]

Thanks! That would be awesome.