Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7EF754C9-15BF-4B8F-8084-114EE33641E0@gmail.com>
Date: Tue, 31 Mar 2015 09:21:51 +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:
> 
> #if __AVX2__
> typedef __m256i           v_uint
> #define jtr_setzero_si    _mm256_setzero_si256
> #define jtr_loadu_si      _mm256_loadu_si256
> #define jtr_movemask_epi8 _mm256_movemask_epi8
> #define jtr_cmpeq_epi8    _mm256_cmpeq_epi8

I think this makes sense. But isn't this pattern already in good use in JtR? I see something like this in DES_bs_b.c:

 #if defined(__AVX__)
 typedef __m256 vtype;
 #define vst(dst, ofs, src)   _mm256_store_ps((float *)((DES_bs_vector *)&(dst) + (ofs)), (src))
 #define vxorf(a, b)  _mm256_xor_ps((a), (b))

This seems to me the pseudo-intrinsics you want. So I guess the problem is that, in JtR, some files use pseudo-intrinsics while some not? If this is the case, IMHO, it would be better to use a unifying definition of all the intrinsics, just as you suggested. Otherwise we'll have to put those CPU detection code in every file that uses CPU-specific intrinsics.


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.