[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
