[cfe-dev] [OpenCL patch] Vector literals are rvalues *updated*

John McCall rjmccall at apple.com
Tue Sep 27 11:06:41 PDT 2011


On Sep 27, 2011, at 4:06 AM, Anton Lokhmotov wrote:
>>> On Sep 21, 2011, at 10:01 AM, John McCall wrote:
>>>> Right.  Ideally, this should just apply to OpenCL vector literals,
>>>> i.e. this should be an r-value:
>>>> (int4) (3,2,1,0)
>>>> and this should be an l-value:
>>>> (int4) {3,2,1,0}
>>> 
>>> On 22 September 2011 00:57, Tanya Lattner wrote:
>>>> Agreed. If you can have it apply only for OpenCL vector literals,
>>>> then it looks good to me.
>>> 
>>> Unfortunately, we can't, as these two forms are indistinguishable in
>>> the AST.  (Strictly speaking, only the first form is valid in OpenCL, 
>>> but as we discussed [1] we should permit the second one as well.)
>> 
>> Two forms being indistinguishable in the AST is theoretically solvable.
> Even if so, I am afraid this will come at the expense of extra code.  More
> importantly, neither OpenCL (see page 164 here:
> http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf) nor AltiVec (see
> page 26 here:
> http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf) permit
> using curly braces for initialising vector literals.  Do we need to worry
> about preserving behaviour of (theoretically existing) code that's illegal
> to start with?

It's not illegal, it's just non-standard.  Notably, it's supported by previous
releases of Apple's OpenCL parser, so it's something we should not break.

John.



More information about the cfe-dev mailing list