Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Dec 2016 21:31:20 +0100
From: Hannes Frederic Sowa <>
To: "Jason A. Donenfeld" <>,
 David Laight <>
Cc: Netdev <>,
 "" <>,
 Jean-Philippe Aumasson <>,
 LKML <>,
 Linux Crypto Mailing List <>,
 "Daniel J . Bernstein" <>,
 Linus Torvalds <>,
 Eric Biggers <>
Subject: Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable


On 15.12.2016 19:50, Jason A. Donenfeld wrote:
> Hi David & Hannes,
> This conversation is veering off course.


> I think this doesn't really
> matter at all. Gcc converts u64 into essentially a pair of u32 on
> 32-bit platforms, so the alignment requirements for 32-bit is at a
> maximum 32 bits. On 64-bit platforms the alignment requirements are
> related at a maximum to the biggest register size, so 64-bit
> alignment. For this reason, no matter the behavior of __aligned(8),
> we're okay. Likewise, even without __aligned(8), if gcc aligns structs
> by their biggest member, then we get 4 byte alignment on 32-bit and 8
> byte alignment on 64-bit, which is fine. There's no 32-bit platform
> that will trap on a 64-bit unaligned access because there's no such
> thing as a 64-bit access there. In short, we're fine.

ARM64 and x86-64 have memory operations that are not vector operations
that operate on 128 bit memory.

How do you know that the compiler for some architecture will not chose a
more optimized instruction to load a 64 bit memory value into two 32 bit
registers if you tell the compiler it is 8 byte aligned but it actually
isn't? I don't know the answer but telling the compiler some data is 8
byte aligned while it isn't really pretty much seems like a call for

Why can't a compiler not vectorize this code if it can prove that it
doesn't conflict with other register users?


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.