[cfe-dev] Giving consistent semantics to extended vectors
natebegeman at me.com
Fri Apr 30 10:13:33 PDT 2010
On Apr 30, 2010, at 5:09 AM, Anton Lokhmotov wrote:
> 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
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)
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev