[cfe-dev] Giving consistent semantics to extended vectors

[Daniel Dunbar]

Hi Anton,

On Tue, May 4, 2010 at 2:56 AM, Anton Lokhmotov <Anton.Lokhmotov at arm.com> 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 (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.

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.

 - Daniel

>> 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.
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>