Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 08 Jul 2015 18:08:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics

On 2015-07-08 17:00, Lei Zhang wrote:
>
>> On Jul 8, 2015, at 12:50 AM, Solar Designer <solar@...nwall.com> wrote:
>>
>> On Tue, Jul 07, 2015 at 11:22:54PM +0800, Lei Zhang wrote:
>>> 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)
>>
>> I have no preference between these two.  I'll defer to magnum.

I don't care but I'd probably pick the latter myself.

>> In DES_bs_b.c, it's the former (accepting the destination as a macro
>> parameter), so maybe we should do the same elsewhere for consistency.
>
> BTW, I think one drawback of these forms is that it's not as convenient to write nested expressions. Like
> 	a = b + c - d
> which, with the current form, could be written as
> 	va = vec_sub(vec_add(vb, vc), vd)

BTW do we even have to use intrinsics for simple things like add and 
sub? Wouldn't the compiler do it for us?

	vtype va, vb = 1, vc = 2, vd = 3;

	va = vb + vc - vd;

I haven't tried that.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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