Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 12 Jul 2015 17:30:27 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics

On Fri, Jul 10, 2015 at 05:47:37PM +0800, Lei Zhang wrote:
> On Jul 7, 2015, at 9:16 PM, Solar Designer <solar@...nwall.com> wrote:
> > On Mon, Jul 06, 2015 at 11:15:41PM -0400, Alain Espinosa wrote:
> >> In Visual C the difference of a simple assignment and a vload is that for the assignment the compiler generate an unaligned SIMD load instruction, and for vload it generates an aligned SIMD load with the usual restriction: if this memory access isn't aligned the required byte amount an exception is raised. In general the performance difference is negligible,  if any.
> > 
> > When I corrected my code (bitslice DES code in JtR) to
> > make the alignment apparent to gcc, it stopped generating the unaligned
> > load instructions, generating the aligned ones instead.
> 
> Could you exemplify how you did it with some code?

It's commit fd875ac13ba0b57b5c84157a440dd03fac714eb1:

Added CC_CACHE_ALIGN to the declaration of DES_bs_all in the non-OpenMP case,
per advice from Richard Biener in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017#c11 and @sevenps tweeting
"Different alignments in definition and declaration is undefined behavior (C11,
alignas)"

So it was a bug fix, and it only applied to non-OpenMP builds (where the
struct was at a fixed address, and gcc's attribute was used to provide
and then to declare alignment).

I now think Alain's message suggests we may in fact need to use the
load/store intrinsics.  His code is probably multi-threaded, so he must
have been accessing the vectors via pointers.  gcc in this case uses
aligned loads; per Alain, apparently Visual C uses unaligned loads.

I don't know if we care about Visual C in particular, but it's a bad
sign.  And JimF has in fact been building jumbo with Visual C.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ