[openssl-dev] Making assembly language optimizations working on Cortex-M3

[Brian Smith]

Andy Polyakov <appro at openssl.org> wrote:

> > Cortex-M platforms are so limited that every bit of performance and
> > space savings matters. So, I think it is definitely worthwhile to
> > support the non-NEON ARMv7-M configuration. One easy way to do this
> > would be to avoid building NEON code when __TARGET_PROFILE_M is defined.
>
> I don't see no __TARGET_PROFILE_M defined by gcc


I see. I didn't realize that GCC didn't emulate this ARM compiler feature.
Never mind.


> Anyway, care to make a suggestion in form of patch? That
> would be suitable even for gcc? [Just in case, no, I don't have ARM's
> compiler, only its manual.]
>

I can try to make a patch to bring BoringSSL's OPENSSL_STATIC_ARMCAP
mechanism to OpenSSL, if you think that is an OK approach.


> > Alternatively, similar to what BoringSSL did, you could have an option
> > that says "instead of doing runtime feature detection, instead detect
> > features at compile time based on __ARM_NEON__ and the like." I think
> > such a configuration would also help the C compiler do whole-program
> > optimization better.
>
> I doubt that, because compiler doesn't look at assembly modules.


For example, in the AES-GCM code, there is a runtime check to decide
between various implementations. With the OPENSSL_STATIC_ARMCAP-like
approach, in theory the compiler's constant propagation and dead code
elimination can work together to automatically optimize away the code paths
that aren't applicable to the current configuration, without needing to
maintain lots of #ifdefs.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160525/a547b678/attachment.html>