<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Andy Polyakov <span dir="ltr"><<a href="mailto:appro@openssl.org" target="_blank">appro@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">> Cortex-M platforms are so limited that every bit of performance and<br>
> space savings matters. So, I think it is definitely worthwhile to<br>
> support the non-NEON ARMv7-M configuration. One easy way to do this<br>
> would be to avoid building NEON code when __TARGET_PROFILE_M is defined.<br>
<br>
</span>I don't see no __TARGET_PROFILE_M defined by gcc</blockquote><div><br></div><div>I see. I didn't realize that GCC didn't emulate this ARM compiler feature. Never mind.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Anyway, care to make a suggestion in form of patch? That<br>
would be suitable even for gcc? [Just in case, no, I don't have ARM's<br>
compiler, only its manual.]<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">> Alternatively, similar to what BoringSSL did, you could have an option<br>
> that says "instead of doing runtime feature detection, instead detect<br>
> features at compile time based on __ARM_NEON__ and the like." I think<br>
> such a configuration would also help the C compiler do whole-program<br>
> optimization better.<br>
<br>
</span>I doubt that, because compiler doesn't look at assembly modules.</blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Brian</div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://briansmith.org/" target="_blank">https://briansmith.org/</a></div><div><br></div></div></div></div></div></div></div>
</div></div>