[cfe-dev] Giving consistent semantics to extended vectors

[Nate Begeman]

On Apr 30, 2010, at 5:09 AM, Anton Lokhmotov wrote:

> Hello,
> 
> I've been investigating how Clang interprets operations on extended vectors
> [those declared with __attribute__((ext_vector_type(n))], in particular with
> respect to the OpenCL semantics, since
> http://clang.llvm.org/docs/LanguageExtensions.html#vectors implies that
> extended vectors have some support for OpenCL constructs.
> 
> My conclusion is that Clang's behaviour with respect to OpenCL considerably
> varies from producing wrong diagnostics to accepting invalid statements and
> rejecting valid statements to silently producing wrong LLVM code.  Couple of
> examples (all vector types have obvious definitions):
> 
> uchar4 vu = (uchar4) true;  
> 	// results in: (0x01, 0x01, 0x01, 0x01)
> 	// must be: (0xff, 0xff, 0xff, 0xff)
> 
> int4 vu = (uint4) vi; // disallowed in OpenCL, accepted by Clang

This is intentional.

> 
> int4 via, vib, vic;
> vic = (via == vib ? via : vib);	// allowed in OpenCL, rejected by Clang:
> 	// error: used type 'int4' where arithmetic or pointer type is
> required

The patch for this has not been submitted back to TOT clang yet.  

> 
> short2 vs, vr; int i;
> vr = vs < i;
> 	// down-conversion and vector widening: disallowed by OpenCL,
> rejected by Clang:
> 	// error: can't convert between vector values of different size
> ('short2' and 'int')
> 	// (clearly, the error message could be more helpful)

Patches welcome.

> 
> My question is whether it anyone has objections to making statements
> involving extended vectors to have by default semantics consistent with
> OpenCL or only have the OpenCL semantics when the LangOpts flag is enabled?

Extended Vectors are meant to support OpenCL-ish operations, but not enforce OpenCL error semantics all the time.

Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100430/899e0262/attachment.html>