On Friday, April 15, 2016 at 5:49:53 PM UTC-4, [email protected] wrote: > > Am Freitag, 15. April 2016 07:43:02 UTC+2 schrieb Jeffrey Walton: >> >> I want to check if there's any opposition to SSE4.1 and SSE4.2 feature >> detection. We can use it for modern algorithms on occasion, like BLAKE2. >> >> I don't plan on hand-coded SSE4.2 ASM, so I'm limiting it to intrinsics >> at this point. We can put it to immediate use with the upcoming BLAKE2. >> > > Could that also be used to guard _mm_insert_epi32 (SSE4.1)? >
Yes, it probably can. > Its usage in rijndael.cpp is already guarded by > CRYPTOPP_BOOL_AESNI_INTRINSICS_AVAILABLE and HasAESNI() and I don't know > about any CPU that supports AESNI but doesn't support SSE4.1, but I've > recently seen some crash dumps because of an invalid instruction exception > in that code (on Windows with Visual Studio 2013). > Yeah, I've seen some [uncommon] problems, too. It appears to have something to do with SecureKey/AES-NI and other CPU features, like AVX and AVX2. I think I've seen the double-quadword multiply used when it was not available. There's probably a small handful of CPUs that witness it. Maybe the first thing to do is to get a good test case together. I'm thinking GCC will be easiest because we can "-maes -mno-avx -mno-avx2". It should tease out any compile time problems. For runtime, we probably need to check under a simulated CPU using libvirt and virsh. Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
