[OpenCL patch] asType, Convert **revised**

Hi Tanya,

As I indicated 2 months ago, we are not in favour of this approach:

I was under the impression that neither was Chris:
nor was Guy:

I think more discussion is needed if this is to go in.

My main concern is that 'as_type' and 'convert_type' [not 'astype' and
'convert'] are not that different from other overloaded OpenCL built-in
functions. While 'as_type' can indeed be represented in LLVM-IR as a
bitcast or shuffle, different flavours of 'convert_type' are effectively
built-in functions, to be implemented either in the library or in the
backend, at which level I'm not sure what e.g. __builtin_convert(i, short,
2, 1) buys you over convert_short_rtz_sat(i).

As I understand, this works for you as follows (please correct me if I'm

OpenCL 'convert_type' functions are #define'd in your internal header file
as e.g.:
#define convert_short_rtz_sat(i) __builtin_convert(i, short, 2, 1)

Parsing a __builtin_convert by Sema::ActOnConvertExpr results in a
ConvertExpr expression.

This expression is then visited by ScalarExprEmitter::VisitConvertExpr,
which creates a call to one of the llvm::Intrinsic::convert?? intrinsics
with { Src, Mode, Sat } parameters [ Mode -> RoundingMode; Sat ->
SaturatedMode ].

So why is this better than just placing declarations for the 'convert_type'
functions in the same header file as for all other built-in functions?

+KEYWORD(__builtin_astype , KEYOPENCL)
+KEYWORD(__builtin_convert , KEYOPENCL)

Please note that these are not keywords according to the OpenCL
specification. [astype -> as_type; convert -> convert_type]

Best regards,