Follow @Openwall on Twitter for new release announcements and other news
[<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.