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 10:37:14 +0800
From: Lei Zhang <>
Subject: Re: extend SIMD intrinsics

> On Jul 7, 2015, at 5:24 AM, Solar Designer <> 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.

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? 

Or further, for a union type defined as 

typedef union {
	vtype32 v32;
	uint32_t s32[...];
} vtype;
vtype v;

Would there be any difference between using v.v32 and using (vtype32)v ?


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.