OpenCL vec_step feature implementation


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.


Guy Benyei


SSG – MGP OpenCL Development Center


opencl_vec_step.patch (31.4 KB)

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.

I don't think we need to mention in the type name that the operator can
take an expression argument as it is common knowledge that sizeof and
alignof can take an expression argument (at least if you are writing
a compiler you should know this!)


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.