On Sat, Jan 28, 2012 at 1:43 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 01/27/2012 09:29 PM, John Salmon wrote:
"Should there even be a cpuid check" is an excellent question. If
the answer is no, it certainly makes some portability headaches go away.
I also don't really think the code should do any cpuid check at all, since
emitting AESNI instructions requires -maes, and whenever you use -maes the compiler is free to emit AESNI instructions whenever it wants.
I have personally come to the conclusion that there should not be any, since that's the only model that is safe with all compilers. Also, this way, users don't pay for what they don't use. They're free to build the cpuid logic on top of it themselves through compiling the code several times with different settings.
The -maes option is gcc-specific. The Intel compiler, for example, does not have an analogous command line option. Unlike with gcc, you can #include <wmmintrin.h> and you can use the _mm_aesenc_si128() without any command line option. I think that it's important for the library to allow the programmer the opportunity to decide about AESNI at compile-time, and also to allow the programmer to defer the decision till runtime. If the decision is deferred till runtime, I don't see how to choose a default without a cpuid check. By the way, the code in aes_hasaesni.hpp that trashes %ebx, and is therefore problematic with -m32 -fPIC is conditionalized on #ifdef BOOST_HAS_AESNI. While I agree that the #ifdef logic to set BOOST_HAS_AESNI needs work, I think it's safe to say that BOOST_HAS_AESNI should never be set when -m32 is in effect.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost