[PATCH] Sema: Implicit scalar-vector conversions

[Stephen Canon]

Ping.

On Mar 26, 2014, at 8:34 PM, Stephen Canon <scanon at apple.com> wrote:

> ExtVectors currently support basic operations with scalar data (which is interpreted as an implicit splat).  However, this support has some serious issues.  Most critically, at present the type of the result depends on operand order:
> 
> 	typedef float __attribute__((ext_vector_type(2))) float2;
> 
> 	float2 x;
> 	double y = 2.0 + x; // reinterprets y as double, scalar double-precision add.
> 	float2 z = x + 2.0; // reinterprets x as float2, does packed single-precision add.
> 
> Both behaviors are pretty busted; the odds are overwhelming that the programmer's intention was to add two to both lanes of x.  What’s worse, +, which is a commutative operator for any reasonable FP type, doesn’t even return the same type when the operand order is flipped.
> 
> This patch makes it so that “real scalar OP vector” is interpreted as “convert the scalar to vector element type and splat, then perform OP”, regardless of operand order or conversion rank of the scalar and vector type (i.e. the type of the vector elements always “wins”, even if the rank of the scalar type is greater).  This is somewhat different from the arithmetic promotions for scalar types, but it is by far the most sensible behavior; it is what most vector programmers want to get.
> 
> This also improves the state of affairs for integer scalars in ExtVector expressions.  When operating on vectors with elements smaller than int, it has until now been necessary to sprinkle in lots of casts:
> 
> 	typedef unsigned char __attribute__((__ext_vector_type__(16))) uchar16;
> 	uchar16 baz(uchar16 x) {
> 	    return x + (unsigned char)2;
> 	}
> 
> The extra cast adds little to nothing, and makes simple expressions overly verbose.  With this patch, the following works just fine:
> 
> 	uchar16 baz(uchar16 x) {
> 	    return x + 2;
> 	}
> 
> I also improved the state of warnings for implicit scalar->vector casts to make it easier to identify suspicious conversions:
> 
> 	short4 bar( ) {
> 	    return 65536;
> 	}
> 
> previously this produced no error or warning.  Now, with -Wconversion we get:
> 
> 	foo.c:9:12: warning: implicit conversion from 'int' to 'short4' changes value from 65536 to 0 [-Wconstant-conversion]
> 
> Thanks in advance for your feedback!
> – Steve
> 
> <vector-implicit-convert.patch>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits