[cfe-dev] Giving consistent semantics to extended vectors

[Anton Lokhmotov]

Hi Daniel and Nate,

> -----Original Message-----
> From: daniel.dunbar at gmail.com [mailto:daniel.dunbar at gmail.com] On
> Behalf Of Daniel Dunbar
> Sent: 04 May 2010 16:33
> To: Anton Lokhmotov
> Overhaul seems a bit strong, as I think the extended vector semantics
> probably make sense, by and large. However, I completely agree that
> extended vectors should have consistent and well documented semantics.
> They were intended to be a "reasonable" implementation of vector
> support for C as well as being useful for OpenCL.
> Unless you really meant overhaul, I recommend filing concrete bug
> reports for places you think the semantics are wrong in C mode.

That's most sensible.  I've been looking at the extended vectors semantics
from the OpenCL perspective but will now try to look from the C perspective
as well.  Ideally, code dealing with extended vectors would check the
current mode and output LLVM-IR with the semantics for this mode.  For
example,  I agree with Nate's explanation that in C mode the casting
operator should generate a bitcast, not a conversion.  In some cases,
however, Clang's behaviour is downright incorrect irrespective of mode, for
example:

int4 via; via++;	

results in a failed assertion "Cannot create binary operator with two
operands of differing type!" (Failed assertions are always bad, especially
when they are so confusing.)

In other cases, I'm not so sure, for example:

uchar4 vc;
vc = (uchar4) false;	// (0x00, 0x00, 0x00, 0x00)
vc = (uchar4) true;	// (0x01, 0x01, 0x01, 0x01)
				// [should be (0xff, 0xff, 0xff, 0xff) in
OpenCL]

(The OpenCL semantics is arguably more useful here, as it allows to use vc
as a mask.)

> -----Original Message-----
> From: Nate Begeman [mailto:natebegeman at me.com]
> Sent: 04 May 2010 16:53
> To: Anton Lokhmotov
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] Giving consistent semantics to extended vectors
> 
> Consistency with OpenCL is achieved via the __builtin_astype() and
> __builtin_convert() functions,  as well as C++ code in Sema.  The
> builtin OpenCL type operators may not have been checked in yet, I can
> follow up on that.
Please do, I can't see these in Clang 2.7 or the trunk.  In fact, grep'ing
Clang 2.7 for OpenCL returns only 26 lines.

> Please file specific bugs for things that are not correct in clang 
> with the OpenCL language enabled.

Since I've specifically tested the behaviour of OpenCL constructs in OpenCL
mode, I could  probably file a couple of dozen of bugs today.  It's clear,
however, that it's just because your changes haven't been merged into the
trunk yet.  I understand that merging the changes is probably a low-priority
activity for you but I can't stress enough how useful it would be resulting
in less duplication and inconsistencies and overall more robust
implementation. 

Best regards,
Anton L.