Brian Smith

I think the best way forward with this is to just run the ed25519/x25519 benchmarks with and without C LTO enabled and see if it matters.

Closing this. I don't think we should be overriding the build configuration in build.rs. The person who requested LTO can disable LTO if they wish.

When we adapt what we did for avx2 to avx512, maybe we should also preserve the whitespace preceding the opcode on the line, prefixing the `.byte` directives with the same...

Well....I mentioned the changes we made for the AVX2 version to the BoringSSL developers and they immediately started removing all of the analogous encoding hacks from BoringSSL about 2 minutes...

I think with the avx512 code, we'll need to be careful about the difference between avx10-256, avx10-512, and avx512. Will they have the same mnemonics but assemble to different encodings?...

BTW, I also agree with you now that it is OK to put the workaround in the aes-gcm-avx10-* file instead of x86_64-xlate.pl. I think as part of that we need...

I will merge https://boringssl.googlesource.com/boringssl/+/46683a56625c60319d45370f74930a5d15a000d4 and https://boringssl.googlesource.com/boringssl/+/b803ed04706c772335abce3fb8b2c1cc43ca2cd4 into main and rebase my PR on top of those, but I expect it will be otherwise the same. since aes-gcm-avx10-x86_64.pl is already in...

I intend to merge all the changes from BoringSSL upstream to remove the Perl instruction encoders. I think the way we did it for VAES+VPCLMUL is less risky than what...

I got some more info on why our workaround could be potentially more hazardous than I expected; see https://github.com/openssl/openssl/issues/27049#issuecomment-2722605271, which I'll quote here: > > Since this would [block](https://github.com/openssl/openssl/issues/27054) -Wa,-msse2avx...

I also see now that GNU as has a syntax for teaching it new instructions; see https://sourceware.org/binutils/docs/as.html#index-insn-directive. I wonder if that could be made to work.