[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D6E7B905-02F2-4DD5-B11F-DFC896E033C5@gmail.com>
Date: Tue, 7 Jul 2015 09:35:18 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics
> On Jul 7, 2015, at 5:24 AM, Solar Designer <solar@...nwall.com> wrote:
>
> On Mon, Jul 06, 2015 at 08:08:21PM +0200, magnum wrote:
>> On 2015-07-06 10:23, Solar Designer wrote:
>>> Regarding possible use of union types, here's a relevant posting by
>>> Alexander Cherepanov:
>>>
>>> http://article.gmane.org/gmane.comp.security.phc/2753
>>>
>>> Nearby postings in this thread are also relevant.
>>
>> I get more depressed the more I read.
>
> Indeed.
>
>> + typedef union {
>> + vtype v;
>> + uint32_t s[SIMD_COEF_32];
>> + } vtype32;
>>
>> + typedef union {
>> + vtype v;
>> + uint64_t s[SIMD_COEF_64];
>> + } vtype64;
>
>
> Why two separate union types, though? We could use a shared type, with
> two arrays in place of s. Would have to call those e.g. s32 and s64.
Do you mean a single type like this?
typedef union {
vtype v;
uint32_t s32[SIMD_COEF_32];
uint64_t s64[SIMD_COEF_64];
} vtype;
> Using those union types inside SSESHA1body(), etc. would be even safer,
> so e.g.:
>
> vtype32 a[SIMD_PARA_SHA1];
> vtype32 b[SIMD_PARA_SHA1];
> [...]
> a[i].v = reload_state->v[i*16+0];
Then why use vtype32 here?
And why not:
a[i] = reload_state[i*16+0];
> but it increases our reliance on the optimizer for producing fast code.
I don't understand this well. Do you mean the compiler might not generate a load for a[i]?
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.
