deps: enable AVX-512 OpenSSL asm with clang - #65136
Merged
nodejs-github-bot merged 1 commit intoAug 11, 2026
Merged
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
Copy link
Copy Markdown
Collaborator
|
Review requested:
|
Sorry, something went wrong.
lemire
force-pushed
the
clang-openssl-avx512-asm
branch
from
c8f1ee4 to
4faf749
Compare
August 8, 2026 13:56
Copy link
Copy Markdown
There was a problem hiding this comment.
Pull request overview
This PR updates OpenSSL build selection logic so clang builds can use the AVX-512-capable pre-generated OpenSSL assembly set, aligning performance-sensitive crypto paths with gcc builds and avoiding silent fallback to the AVX2-only asm set.
Changes:
- Extend the deps/openssl/openssl.gyp condition that selects openssl_asm*.gypi to also accept sufficiently new llvm_version (LLVM/clang integrated assembler).
- Apply the same selection logic to both the main OpenSSL target and the FIPS module target.
deps/openssl/openssl.gyp:119
- Same issue as above for the FIPS target: llvm_version can bypass the nasm_version check on Windows, but Windows still uses nasm.exe to assemble these files. This may incorrectly select the AVX-512 asm set when NASM is unavailable/too old.
}, 'gas_version and v(gas_version) >= v("2.26") or '
'nasm_version and v(nasm_version) >= v("2.11.8") or '
'llvm_version and v(llvm_version) >= v("8.0")', {
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
Comment thread
deps/openssl/openssl.gyp
Comment on lines
38
to
+40
| }, 'gas_version and v(gas_version) >= v("2.26") or ' | ||
| 'nasm_version and v(nasm_version) >= v("2.11.8")', { | ||
| 'nasm_version and v(nasm_version) >= v("2.11.8") or ' | ||
| 'llvm_version and v(llvm_version) >= v("8.0")', { |
Copy link
Copy Markdown
Member
Author
There was a problem hiding this comment.
I expect that if llvm_version indicates a recent version, then nasm should be adequate to build the resulting objects. You'd have a misconfigured system otherwise.
Sorry, something went wrong.
avivkeller
approved these changes
Aug 8, 2026
Copy link
Copy Markdown
Collaborator
Sorry, something went wrong.
Node.js ships two pre-generated sets of OpenSSL assembly: `asm`, which contains the AVX-512 routines, and `asm_avx2`, which does not. The set is picked in deps/openssl/openssl.gyp based on `gas_version` or `nasm_version`, but configure.py only reports `gas_version` when the compiler is not clang, because clang uses its own integrated assembler and has no GNU assembler version to report. Consequently every clang build silently falls back to the AVX-512-less `asm_avx2` set, with no warning. The result is that `ossl_vaes_vpclmulqdq_capable()` is assembled as a stub that always returns 0, so OpenSSL never selects `ossl_aes_gcm_encrypt_avx512()` and uses the older AES-NI path instead. On an Intel Xeon Gold 6548N this costs roughly 1.6x on AES-256-GCM and 1.8x on both ChaCha20-Poly1305 and RSA-2048 signing. This is not limited to custom builds: BUILDING.md documents that the official linux-x64 binaries are produced with clang, and the shipped v25.x and v26.x binaries contain the stub. Accept `llvm_version` in the condition, the way deps/openssl/openssl.gypi already does for the AVX2 set. clang's integrated assembler has handled AVX512IFMA since 3.9 and VAES / VPCLMULQDQ since 6.0; 8.0 is used as a conservative floor, well below the clang 19.1 that Node.js already requires.
lemire
force-pushed
the
clang-openssl-avx512-asm
branch
from
4faf749 to
322485d
Compare
August 8, 2026 14:49
jasnell
approved these changes
Aug 8, 2026
lpinca
approved these changes
Aug 8, 2026
Copy link
Copy Markdown
Collaborator
Sorry, something went wrong.
Copy link
Copy Markdown
Collaborator
Sorry, something went wrong.
aduh95
pushed a commit
that referenced
this pull request
Aug 13, 2026
Node.js ships two pre-generated sets of OpenSSL assembly: `asm`, which contains the AVX-512 routines, and `asm_avx2`, which does not. The set is picked in deps/openssl/openssl.gyp based on `gas_version` or `nasm_version`, but configure.py only reports `gas_version` when the compiler is not clang, because clang uses its own integrated assembler and has no GNU assembler version to report. Consequently every clang build silently falls back to the AVX-512-less `asm_avx2` set, with no warning. The result is that `ossl_vaes_vpclmulqdq_capable()` is assembled as a stub that always returns 0, so OpenSSL never selects `ossl_aes_gcm_encrypt_avx512()` and uses the older AES-NI path instead. On an Intel Xeon Gold 6548N this costs roughly 1.6x on AES-256-GCM and 1.8x on both ChaCha20-Poly1305 and RSA-2048 signing. This is not limited to custom builds: BUILDING.md documents that the official linux-x64 binaries are produced with clang, and the shipped v25.x and v26.x binaries contain the stub. Accept `llvm_version` in the condition, the way deps/openssl/openssl.gypi already does for the AVX2 set. clang's integrated assembler has handled AVX512IFMA since 3.9 and VAES / VPCLMULQDQ since 6.0; 8.0 is used as a conservative floor, well below the clang 19.1 that Node.js already requires. PR-URL: #65136 Reviewed-By: Aviv Keller <me@aviv.sh> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
aduh95
pushed a commit
that referenced
this pull request
Aug 25, 2026
Node.js ships two pre-generated sets of OpenSSL assembly: `asm`, which contains the AVX-512 routines, and `asm_avx2`, which does not. The set is picked in deps/openssl/openssl.gyp based on `gas_version` or `nasm_version`, but configure.py only reports `gas_version` when the compiler is not clang, because clang uses its own integrated assembler and has no GNU assembler version to report. Consequently every clang build silently falls back to the AVX-512-less `asm_avx2` set, with no warning. The result is that `ossl_vaes_vpclmulqdq_capable()` is assembled as a stub that always returns 0, so OpenSSL never selects `ossl_aes_gcm_encrypt_avx512()` and uses the older AES-NI path instead. On an Intel Xeon Gold 6548N this costs roughly 1.6x on AES-256-GCM and 1.8x on both ChaCha20-Poly1305 and RSA-2048 signing. This is not limited to custom builds: BUILDING.md documents that the official linux-x64 binaries are produced with clang, and the shipped v25.x and v26.x binaries contain the stub. Accept `llvm_version` in the condition, the way deps/openssl/openssl.gypi already does for the AVX2 set. clang's integrated assembler has handled AVX512IFMA since 3.9 and VAES / VPCLMULQDQ since 6.0; 8.0 is used as a conservative floor, well below the clang 19.1 that Node.js already requires. PR-URL: #65136 Reviewed-By: Aviv Keller <me@aviv.sh> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I was trying to find out which compile was better for compiling Node.js : GCC or LLVM/clang. One of my benchmark showed that GCC was massively better. After investigating, I found that it was a configuration issue that disabled part of OpenSSL under AVX-512. Note that I am using Linux.
We don't need to worry about Apple Clang because AVX-512 on Apple systems is a narrow niche.
Node.js ships two pre-generated sets of OpenSSL assembly: asm, which contains the AVX-512 routines, and asm_avx2, which does not. The set is picked in deps/openssl/openssl.gyp based on gas_version or nasm_version, but configure.py only reports gas_version when the compiler is not clang, because clang uses its own integrated assembler and has no GNU assembler version to report. Consequently every clang build silently falls back to the AVX-512-less asm_avx2 set, with no warning.
The result is that ossl_vaes_vpclmulqdq_capable() is assembled as a stub that always returns 0, so OpenSSL never selects ossl_aes_gcm_encrypt_avx512() and uses the older AES-NI path instead. On a Zen 5 machine this costs roughly 1.6x on AES-256-GCM, 1.7x on ChaCha20-Poly1305 and 1.8x on RSA-2048 signing.
Accept llvm_version in the condition, the way deps/openssl/openssl.gypi already does for the AVX2 set. clang's integrated assembler has handled AVX512IFMA since 7.0 at least and VAES / VPCLMULQDQ since 7.0 at least; 8.0 is used as a conservative floor, well below the clang that Node.js is built with today.