[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <0F8C9717-0DEF-4613-A8C5-CA621C86C81D@gmail.com>
Date: Wed, 16 Sep 2015 12:29:12 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Strict aliasing in SIMD code
On Sep 16, 2015, at 1:25 AM, Solar Designer <solar@...nwall.com> wrote:
>
> On Tue, Sep 15, 2015 at 11:33:04PM +0800, Lei Zhang wrote:
>> Maybe we need not worry about strict-aliasing anymore when using SIMD intrinsics, as (most) compilers are already taking care of this issue for us.
>
> For x86, it appears so (and it may be why crypto_scrypt-sse.c didn't
> break, while -nosse did). For other archs, it's less obvious. gcc does
> sometimes emit strict aliasing violation warnings for my intrinsics
> code in DES_bs_b.c. I am not entirely sure, but I think I only saw
> those warnings in non-x86 builds (meaning NEON and AltiVec).
I think AltiVec and NEON should be fine. As they both have distinctive loads and stores for different vector types, unlike x86, there's no need to cast between vector and scalar pointers as long as we stick to using vload and vstore instead of directly dereferencing pointers.
As a result, we'll need to revise our current code a bit: distinguish between vtype32 and vtype64 (vector type of int32 and int64), and have different versions of vload and vstores.
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.
