Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150707144916.GA9127@openwall.com>
Date: Tue, 7 Jul 2015 17:49:16 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics

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.

Also, cast to union hasn't historically been supported in C.  Perhaps
it's OK for us to assume C99 already, but let's not over-complicate
things unnecessarily.

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

Would the latter even compile?  While cast to union is a thing, I think
cast to union member type isn't... but I could be wrong?

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.

Alexander

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.