[cfe-dev] OpenCL vec_step feature implementation

[Peter Collingbourne]

On Wed, Feb 16, 2011 at 01:04:13PM +0100, Sebastian Redl wrote:
> 
> On 15.02.2011, at 18:42, Peter Collingbourne wrote:
> 
> > On Tue, Feb 15, 2011 at 05:20:16PM +0200, Benyei, Guy wrote:
> >> Hello,
> >> 
> >> Attached our implementation for the OpenCL vec_step built in function (OpenCL 1.1 specs, 6.11.12), and a test for validating it.
> >> We'd like to get your feedback, and eventually we'd like to contribute this code to the open source development trunk.
> >> 
> >> The vec_step function takes an expression or a type as argument, and returns 1 for scalar types, or the number of vector elements for vector types.
> >> Since vec_step might take types as argument, it cannot be implemented as a standard function, it is rather similar to sizeof and alignof expressions. In this implementation, we take advantage of the existing SizeOfAlignOfExpr class and the functions manipulating it, and we add vec_step to this expression class.
> >> 
> >> I know that the SizeOfAlignOf name is not exactly right after this change; however I still think that this name covers the main feature handled by this class. Calling it SizeOfAlignOfVecStep would be quite long, and might get longer over time. We might change the name to something like UnaryOperatorWithExprOrType - still long and ugly, but generic. I'll be happy to get your ideas about the name.
> > 
> > TypePropertyExpr (or perhaps UnaryTypePropertyExpr) may be a good
> > name, as it reflects the fact that the operator's result reflects some
> > property of the (type of the) operand (size, alignment, vector size)
> > which I think is the most important characteristic of this family
> > of operators.
> 
> While this reasoning is correct, there's high potential for confusion with UnaryTypeTraitExpr, which does the same, but has the important difference that type traits cannot be applied to expressions.

To an extent I agree with this point.  I initially decided not
to bring up UnaryTypeTraitExpr on the basis that "trait" means
a different thing to "property" but now that I think about it
more this does not make much sense.  We should be consistent with
terminology and I think "trait" is the term we should use here.

What about UnaryExprOrTypeTraitExpr?  While it is long and slightly
misleading (we don't deal with "expression traits") it does present
this difference between the two expression types.

Also, if we ever needed expression traits this could be consistently
added as a UnaryExprTraitExpr expression type.

Thanks,
-- 
Peter