Ping.
On Mar 26, 2014, at 8:34 PM, Stephen Canon <[email protected]> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
