[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