[cfe-dev] Giving consistent semantics to extended vectors

[Nate Begeman]

On May 4, 2010, at 2:56 AM, Anton Lokhmotov wrote:

> Hi Nate,
> 
>> Extended Vectors are meant to support OpenCL-ish operations,
>> but not enforce OpenCL error semantics all the time.
> 
> There are two questions here: 
> 
> (1) should Extended Vectors have OpenCL semantics by default?
> (2) should Extended Vectors have sensible semantics?
> 
> The answer to (2) is "yes".  For example, the type casting operator ()
> currently results in reinterpretation e.g.
> 
> int4 vi = (int4) 0x1;    // vi = (  0x00000001,   0x00000001,   0x00000001,
> 0x00000001)
> float4 vf = (float4) vi; // disallowed in OpenCL, accepted by Clang, results
> in:
> 				 // vf = (1.401298e-45, 1.401298e-45,
> 1.401298e-45, 1.401298e-45)
> 
> but should arguably result in conversion, as reinterpretation can be
> achieved by memcpy but conversion would require element-wise copying.

No, it should not result in conversion.  This behavior is specifically intended to allow intermixing of vector and extended vector types, since one of the most common things you want to do is bitconvert an extended vector type for use with an SSE/AltiVec intrinsic.  This is not a bug.  When compiling with the OpenCL language flag enabled, Sema can easily reject this particular explicit cast, but it should not be an illegal operation on Extended Vectors in general.

> 
> So I suggest to overhaul the implementation of Extended Vectors, making
> their semantics sensible (and properly documenting it), whilst achieving
> consistency with OpenCL only where possible.

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.  I believe Extended Vectors already have sensible semantics and are generally consistent with OpenCL, as they have been used to make a conforming OpenCL implementation.  Please file specific bugs for things that are not correct in clang with the OpenCL language enabled.

Nate