Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <28DAFB47-3CEA-4151-9510-03543C015DEB@gmail.com>
Date: Tue, 7 Jul 2015 23:22:54 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics


> On Jul 7, 2015, at 10:49 PM, Solar Designer <solar@...nwall.com> wrote:
> 
> On Tue, Jul 07, 2015 at 10:37:14AM +0800, Lei Zhang wrote:
>> Using a union type, the pseudo-intrinsics would be written this way (for AltiVec):
>> 
>> #vadd_epi32(x, y)	(vtype)vec_add(x.v32, y.v32)
>> #vadd_epi64(x, y)	(vtype)vec_add(x.v64, y.v64)
>> 
>> Does the type casting here violate strict aliasing? 
> 
> I find it weird.  Why would you need it?  Instead, assign the vec_*()
> intrinsics outputs to .v fields.

You mean, in-place updating like this(?):

#vadd_epi32(z, x, y)	z.v32 = vec_add(x.v32, y.v32)

or just change the user code:

z.v32 = vadd_epi32(x, y)


This makes sense. But either way, we'll need to refactor every use of pseudo-intrinsic in JtR to the new form.


> More importantly, why are you proposing to define separate vector types
> for different element sizes?  I don't object to this, I merely ask.
> There might be a good reason for it.

For code just like the above:

#vadd_epi32(z, x, y)	z.v32 = vec_add(x.v32, y.v32)
#vadd_epi64(z, x, y)	z.v64 = vec_add(x.v64, y.v64)


With a single vector type, they would be written like:

#vadd_epi32(z, x, y)	z.v = vec_add(x.v, y.v)
#vadd_epi64(z, x, y)	z.v = (vtype32)vec_add((vtype64)x.v, (vtype64)y.v)


I think either way is fine. I just feel the former is clearer. Or maybe there's some better way than those two?


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.