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

alex_rosenberg at playstation.sony.com alex_rosenberg at playstation.sony.com
Tue Sep 27 09:47:00 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?

The AltiVec PIM is not the only reference here. The "C/C++ Language Extensions for Cell Broadband Engine Architecture" <http://goo.gl/akXE0> updates the AltiVec PIM with additional syntax. Unfortunately, the GCC community took it upon themselves to dislike the original AltiVec PIM syntax and invented their own using curly braces which then became enshrined in this CBEA reference. See <http://gcc.gnu.org/ml/gcc/2001-11/msg01237.html>.

-----------------------------------------
Alex Rosenberg
Manager, Platform Architecture
Sony Computer Entertainment America, Inc.





More information about the cfe-dev mailing list