Update to the OpenSSL Assembler Optimization Policy
As more and more assembly-optimized code is added to OpenSSL to achieve the best possible performance, the time has come to update our Assembler Optimizations policy so that it at least addresses the use of compiler intrinsic code.
Currently, the preferred method is to use perlasm, which is not always the best option.
This pull request adds the following to the policy above:
In exceptional cases, compiler intrinsic code can be used. All supported toolchains for the particular platform must support it.
If you have any comments on this change, please let us know - ideally in the discussion below.
Thanks,
Milan
Paul DaleTue 16 Jun 2026 11:40PM
I agree.
Intrinsics benefit multiple architectures.
PQ algorithms are quite compatible with the capabilities intrinsics provide (vectorisation primarily).
Randall BeckerWed 17 Jun 2026 5:24PM
I am in the same camp as the "use intrinsics". We did this to access the x86 randomizer for the 3.0.x series. Some platforms publish subsets of intrinsics, so as long as we detect the ones being used and provide alternatives where none are supported, this is fine.
Billy BrumleyThu 18 Jun 2026 5:03AM
IMHO no one should be writing hand optimized assembly. But there are a lot of perverse incentives for why that keeps happening, even after the academic community has given us the tools to automate that in a formally verified way.
So given the choice between "intrinsics" vs "asm", sure, allowing intrinsics is a step in the right direction.
Milan BrozThu 18 Jun 2026 12:51PM
ok, pul request changed to:
Compiler intrinsic code can be used where it makes sense.
Selection of an implementation for a particular architecture must always be based on runtime detection of the CPU's capabilities.
It is not acceptable to fail during runtime due to missing CPU capabilities unless the build configuration explicitly targets the concrete CPU family that provides the capability.
Peter Gutmann ·Tue 16 Jun 2026 11:36PM
Why "exceptional" thought? I'd agree with Tom Cosgrove's comment about using intrinsics where possible and letting the compiler do the rest of the work. That is, don't ban asm, but use intrinsics where possible rather than only in exceptional circumstances.