| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Despite the code having runtime detection of NEON and crypto extensions,
the optimized code using those instructions is disabled at build time on
platforms where the compiler doesn't enable NEON by default of with the
flags it's given for the caller code.
In the case of gcm, this goes as far as causing a build error.
What is needed is for the optimized code to be enabled in every case,
letting the caller code choose whether to use that code based on the
existing runtime checks.
But this can't be simply done either, because those optimized parts of
the code need to be built with NEON enabled, unconditionally, but that
is not compatible with platforms using the softfloat ABI. For those,
we need to use the softfp ABI, which is compatible. However, the softfp
ABI is not compatible with the hardfp ABI, so we also can't
unconditionally use the softfp ABI, so we do so only when the compiler
targets the softfloat ABI, which confusingly enough is advertized via
the `__SOFTFP__` define.
Differential Revision: https://phabricator.services.mozilla.com/D59451
|
