[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Sep 2015 20:25:38 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Strict aliasing in SIMD code
Hi Lei,
On Tue, Sep 15, 2015 at 11:33:04PM +0800, Lei Zhang wrote:
> I was thinking about polishing the pseudo-intrinsics for NEON and AltiVec when this topic came to me. We've discussed it before, but I don't think we've really fixed this issue in JtR so far. I found an interesting SO link that's related to our problem and might be worth reading: http://stackoverflow.com/questions/24787268/how-to-implement-mm-storeu-epi64-without-aliasing-problems
Thanks. Some interesting stuff there.
Regarding:
""GCC does do strict-aliasing, but from my experience, not across
function boundaries." Even for inlined functions? Nemo Jul 16 '14 at
18:38"
I can say that GCC does strict-aliasing across boundaries of inlined
functions. This is what broke crypto_scrypt-nosse.c in some builds.
> 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).
Alexander
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.
