[cfe-dev] Giving consistent semantics to extended vectors

[Anton Lokhmotov]

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 (1) is "no".  I understand that providing OpenCL semantics is
not always possible/desirable.  For example, OpenCL programs can use extra
as_type() and convert_type() operators which are unavailable in C.  Thus,
disallowing e.g.

int4 vi = (int4) -1;   // vi = (-1, -1, -1, -1)
uint4 vu = (uint4) vi; // disallowed in OpenCL, accepted by Clang, results
in:
                       // vu = (0xffffffff, 0xffffffff, 0xffffffff,
0xffffffff)

would mean C programs have to do memcpy for reinterpretation and
element-wise copying for conversion.

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.

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.

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

It's difficult to work on patches without knowing what's already
implemented/planned and might be committed soon.  If you could commit your
patches, then it would avoid duplication of work and/or inconsistencies.  Do
you think you could do that?

Best regards,
Anton.