deps: enable AVX-512 OpenSSL asm with clang by lemire · Pull Request #65136 · nodejs/node

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire · 2026-08-08T13:53:03Z

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.

nodejs-github-bot · 2026-08-08T13:53:08Z

Review requested:

@nodejs/gyp
@nodejs/security-wg

Copilot

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.

Suppressed comments (1)

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.

lemire · 2026-08-08T19:29:30Z

 }, '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")', {


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.

nodejs-github-bot · 2026-08-08T14:20:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75647/

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.

nodejs-github-bot · 2026-08-11T00:59:29Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75757/

nodejs-github-bot · 2026-08-11T11:38:33Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75774/

nodejs-github-bot · 2026-08-11T14:09:19Z

Landed in 175cd52

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>

lemire requested a lite review from Copilot August 8, 2026 13:53

nodejs-github-bot added dependencies PRs that add, update, or configure Node.js dependencies. needs-ci PRs that need a full CI run. openssl Issues and PRs related to the OpenSSL dependency. labels Aug 8, 2026

Copilotstarted reviewing on behalf of lemire August 8, 2026 13:53 View session

lemire requested review from anonrig, mcollina and targos August 8, 2026 13:54

lemire force-pushed the clang-openssl-avx512-asm branch from c8f1ee4 to 4faf749Compare August 8, 2026 13:56

lemire added the request-ci Add this label to start a Jenkins CI on a PR. label Aug 8, 2026

CopilotAI reviewed Aug 8, 2026
View reviewed changes

avivkeller approved these changes Aug 8, 2026
View reviewed changes

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Aug 8, 2026

lemire force-pushed the clang-openssl-avx512-asm branch from 4faf749 to 322485dCompare August 8, 2026 14:49

jasnell approved these changes Aug 8, 2026
View reviewed changes

lpinca approved these changes Aug 8, 2026
View reviewed changes

lemire added request-ci Add this label to start a Jenkins CI on a PR. author ready PRs with CI started, the required approvals, and no outstanding review comments. labels Aug 11, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Aug 11, 2026

richardlau added the commit-queue PRs queued for automated landing through the Commit Queue. label Aug 11, 2026

nodejs-github-bot merged commit 175cd52 into nodejs:mainAug 11, 2026
75 of 77 checks passed

nodejs-github-bot removed the commit-queue PRs queued for automated landing through the Commit Queue. label Aug 11, 2026

github-actionsBot mentioned this pull request Aug 25, 2026
2026-08-26, Version 26.8.0 (Current) #65551
Merged