[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57be3b0d7e7fee0de4d85c535efcb606@smtp.hushmail.com>
Date: Mon, 06 Jul 2015 23:53:22 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics
On 2015-07-06 23:24, Solar Designer 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;
>
> Disregarding the unclear status of arrays within unions as it relates to
> strict aliasing rules, this is what I would suggest too.
>
> This is probably the most reasonable approach for us now.
>
> 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.
>
>> - void SSESHA1body(vtype* _data, ARCH_WORD_32 *out, ARCH_WORD_32
>> *reload_state, unsigned SSEi_flags)
>> + void SSESHA1body(vtype32 *data, vtype32 *out, vtype32 *reload_state,
>> uint32_t SSEi_flags)
>> {
>> ...
>> vtype a[SIMD_PARA_SHA1];
>> vtype b[SIMD_PARA_SHA1];
>> ...
>> SHA1_PARA_DO(i)
>> {
>> - a[i] = vload((vtype*)&reload_state[i*16*VS32+0*VS32]);
>> + a[i] = vload(reload_state->v[i*16+0]);
>> ...
>
> Why not simply:
>
> a[i] = reload_state->v[i*16+0];
>
> or why not simply use reload_state->v[i*16+0] in a subsequent expression
> in place of a[i]? I think use of a[i] may only be needed when we start
> doing computation, not for the load.
Perhaps, I just picked a couple existing lines to demonstrate. Alain use
to do things like that, right? You can still spot reference code in our
functions, while his code looks totally different.
>> Would this take us forward or back?
>
> Forward, I hope.
Lei, are you with us here? How about trying this out while adding
Altivec support?
> 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];
>
> but it increases our reliance on the optimizer for producing fast code.
Yes I think that would be the final blow against having them put into
registers but that's just a gut feeling. We could try it.
magnum
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.
