|
Message-Id: <20AA6375-2994-4100-88BF-34C7FC359980@gmail.com> Date: Wed, 1 Apr 2015 12:15:54 +0800 From: Lei Zhang <zhanglei.april@...il.com> To: john-dev@...ts.openwall.com Subject: Re: New SIMD generations, code layout > On Mar 31, 2015, at 12:09 AM, magnum <john.magnum@...hmail.com> wrote: > > I just made a rough experimental version of raw-sha1-ng with AVX2 > support (not committed). It's definitely worth it. But to the point, a > question popped up. The code is now loaded with things like this: > > #if __AVX2__ > __m256i Z = _mm256_setzero_si256(); > __m256i X = _mm256_loadu_si256(key); > __m256i B; > uint32_t len = _mm256_movemask_epi8(_mm256_cmpeq_epi8(X, Z)); > #else > __m128i Z = _mm_setzero_si128(); > __m128i X = _mm_loadu_si128(key); > __m128i B; > uint32_t len = _mm_movemask_epi8(_mm_cmpeq_epi8(X, Z)); > #endif I just tried to add MIC support to rawSHA256_ng, but the file seems a bit hardcoded for SSE and I have to write "#ifdef __MIC__ {...}" (like the code above) everywhere. It almost feels like I'm rewriting the whole file, copying the original code and then replacing every occurrence of "_mm256" with "_mm512". I don't feel this is the right way to go. I guess other files that use SSE intrinsics are more or less the same case. I'm curious how magnum handled this when adding AVX2 support. Is there a better way without using pseudo-intrinsics? Maybe we can start implementing the pseudo-intrinsics now. Those used in DES_bs_b.c make a good reference, but not comprehensive enough. What's your opinion? I may start doing this if it's appropriate. Lei
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.