Usage of compiler intrinsic functions - our approach?
https://github.com/openssl/openssl/pull/29178 introduces compiler intrinsics for Intel architecture and I see the similar idea in one of recent RISC-V PRs.
Personally I prefer the intrinsic approach because it's a regular C instead of ASM.
This approach requires that
1. the compiler should support the necessary intrinsics
2. the necessary flags should be indicated at compile time
3. the run-time detection, as currently is implemented for assembler files
(3) is trivial, (1) and (2) requires some extra efforts, however.
What do you think? Should we recommend this approach for future?
Dmitry Belyavsky Sat 20 Dec 2025 5:07PM
@Neil Horman Do you want me to raise an issue in `openssl/project`?
Neil Horman Sat 20 Dec 2025 9:12PM
@Dmitry Belyavsky Maybe not yet, lets see what other comitters here think first
Neil Horman Sun 21 Dec 2025 7:52PM
Note, i have created a PR:
https://github.com/openssl/openssl/pull/29482
to add testing against gcc9 (our oldest compiler version supported), so, if we decide to move forward with this, we should be somewhat covered by CI for potential failures.
Dmitry Belyavsky Sun 21 Dec 2025 8:47PM
@Neil Hormanthank you very much!
Tom Cosgrove Fri 19 Dec 2025 4:34PM
I am generally in favour of intrinsics. We write the code, and then let the compiler take care of optimising for particular microarchitectures, unrolling loops, and the user can decide if they want to prioritise code size or performance.
Paul Dale Sat 20 Dec 2025 3:51AM
I'm okay with intrinsics in the code if they are properly guarded so compiler support is ensured. Several years ago I used intrinsics in include/internal/safe_math.h. I had compile time guards and a fall-back path so the code always worked.
Compile time guards fix the micro-architecture whereas our assembly is generally run time dispatched. This isn't a problem for the referenced PR but is there a reasonable way to do run time dispatch with intrinsics?
I don't think that intrinsic use should replace our assembly. The assembly still has the potential to be more performant.
Dmitry Belyavsky Sat 20 Dec 2025 5:12PM
@Paul Dale I don't think they should replace the current implementations - but we should be ready for new intrinsic-based contributions.
Paul Yang Thu 25 Dec 2025 3:16AM
I am a big fan of intrinsics so I support @Dmitry Belyavsky 's proposal of being ready with intrinsics
Neil Horman · Fri 19 Dec 2025 2:52PM
Generally the use of intrinsics seems like a good idea to me, if for no other reason than intrinsics seem easier to maintain to me.
That said, like (1) above notes, the compiler has to support the used intrinsics, and our CI isn't great about ensuring that we do builds on the minimum and maximum supported compiler versions for each supported platform (thinking only of primary/secondary platforms at the moment, setting aside the can of worms that is the community supported platform list).
I would think that precursor to recommending the use of intrinsics over hand rolled asm would be that we ensure at least one CI job with the minimum supported compiler version to catch build failures when newer intrinsics are used (which we should probably be doing anyway).