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

On Tue, Jul 07, 2015 at 09:35:18AM +0800, Lei Zhang wrote:
> 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:
> >> + 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;

Yes, but you can't call both the vector inside it and the union type
itself vtype at once.  You'll have to choose different names.

> > 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?

Merely because I was commenting on magnum's original proposal.
Of course, we'd use the 3-field union type like yours above if we
introduce it.

> And why not:
> 
> 	a[i] = reload_state[i*16+0];

We could, but I suspect the compiler would be more likely to do
something like an inline memcpy() instead of a SIMD load then.

> > 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]?

No, I mean the compiler would be e.g. more likely to put a[] on the
stack rather than in SIMD registers, or do other inefficient things.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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