On Thu, Oct 11, 2012 at 11:25 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
> Hello,
>
> this documents both my latest C++ FE patch, something I noticed while doing
> the FE work (shifts can mix vectors and scalars) and the result of the
> conversation with Richard B on how the middle-end should model vector truth
> values. The patch is a little early compared to the code (VEC_COND_EXPR
> still requires a comparison as first argument) but that shouldn't take too
> long to fix and it documents the intent.
Ok.
Many thanks,
Richard.
> 2012-10-11 Marc Glisse <marc.gli...@inria.fr>
>
> * doc/extend.texi (Vector Extensions): C++ improvements.
> * doc/generic.texi (LSHIFT_EXPR, RSHIFT_EXPR): Mixed vector-scalar.
> (LT_EXPR, LE_EXPR, GT_EXPR, GE_EXPR, EQ_EXPR, NE_EXPR): Specify
> the vector case.
> (VEC_COND_EXPR): Document it.
>
> --
> Marc Glisse
> Index: doc/generic.texi
> ===================================================================
> --- doc/generic.texi (revision 192348)
> +++ doc/generic.texi (working copy)
> @@ -1381,21 +1381,22 @@ a fixed-point value to a floating-point
>
> @item LSHIFT_EXPR
> @itemx RSHIFT_EXPR
> These nodes represent left and right shifts, respectively. The first
> operand is the value to shift; it will always be of integral type. The
> second operand is an expression for the number of bits by which to
> shift. Right shift should be treated as arithmetic, i.e., the
> high-order bits should be zero-filled when the expression has unsigned
> type and filled with the sign bit when the expression has signed type.
> Note that the result is undefined if the second operand is larger
> -than or equal to the first operand's type size.
> +than or equal to the first operand's type size. Unlike most nodes, these
> +can have a vector as first operand and a scalar as second operand.
>
>
> @item BIT_IOR_EXPR
> @itemx BIT_XOR_EXPR
> @itemx BIT_AND_EXPR
> These nodes represent bitwise inclusive or, bitwise exclusive or, and
> bitwise and, respectively. Both operands will always have integral
> type.
>
> @item TRUTH_ANDIF_EXPR
> @@ -1475,25 +1476,26 @@ allows the backend to choose between the
> @code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target.
>
> @item LT_EXPR
> @itemx LE_EXPR
> @itemx GT_EXPR
> @itemx GE_EXPR
> @itemx EQ_EXPR
> @itemx NE_EXPR
> These nodes represent the less than, less than or equal to, greater
> than, greater than or equal to, equal, and not equal comparison
> -operators. The first and second operand with either be both of integral
> -type or both of floating type. The result type of these expressions
> -will always be of integral or boolean type. These operations return
> -the result type's zero value for false, and the result type's one value
> -for true.
> +operators. The first and second operands will either be both of integral
> +type, both of floating type or both of vector type. The result type of
> +these expressions will always be of integral, boolean or signed integral
> +vector type. These operations return the result type's zero value for
> +false, the result type's one value for true, and a vector whose elements
> +are zero (false) or minus one (true) for vectors.
>
> For floating point comparisons, if we honor IEEE NaNs and either operand
> is NaN, then @code{NE_EXPR} always returns true and the remaining operators
> always return false. On some targets, comparisons against an IEEE NaN,
> other than equality and inequality, may generate a floating point
> exception.
>
> @item ORDERED_EXPR
> @itemx UNORDERED_EXPR
> These nodes represent non-trapping ordered and unordered comparison
> operators. These operations take two floating point operands and
> @@ -1762,20 +1764,31 @@ is half as wide. The elements of the tw
> (concatenated) to form the output vector.
>
> @item VEC_PACK_FIX_TRUNC_EXPR
> This node represents packing of elements of the two input vectors into the
> output vector, where the values are converted from floating point
> to fixed point. Input operands are vectors that contain the same number
> of elements of a floating point type. The result is a vector that contains
> twice as many elements of an integral type whose size is half as wide. The
> elements of the two vectors are merged (concatenated) to form the output
> vector.
> +
> +@item VEC_COND_EXPR
> +These nodes represent @code{?:} expressions. The three operands must be
> +vectors of the same size and number of elements. The second and third
> +operands must have the same type as the entire expression. The first
> +operand is of signed integral vector type. If an element of the first
> +operand evaluates to a zero value, the corresponding element of the
> +result is taken from the third operand. If it evaluates to a minus one
> +value, it is taken from the second operand. It should never evaluate to
> +any other value. In contrast with a @code{COND_EXPR}, all operands are
> +always evaluated.
> @end table
>
>
> @c ---------------------------------------------------------------------
> @c Statements
> @c ---------------------------------------------------------------------
>
> @node Statements
> @section Statements
> @cindex Statements
> Index: doc/extend.texi
> ===================================================================
> --- doc/extend.texi (revision 192348)
> +++ doc/extend.texi (working copy)
> @@ -6857,21 +6857,21 @@ operate in a similar manner. Likewise,
> minus or complement operators on a vector type is a vector whose
> elements are the negative or complemented values of the corresponding
> elements in the operand.
>
> It is possible to use shifting operators @code{<<}, @code{>>} on
> integer-type vectors. The operation is defined as following: @code{@{a0,
> a1, @dots{}, an@} >> @{b0, b1, @dots{}, bn@} == @{a0 >> b0, a1 >> b1,
> @dots{}, an >> bn@}}@. Vector operands must have the same number of
> elements.
>
> -For the convenience in C it is allowed to use a binary vector operation
> +For convenience, it is allowed to use a binary vector operation
> where one operand is a scalar. In that case the compiler will transform
> the scalar operand into a vector where each element is the scalar from
> the operation. The transformation will happen only if the scalar could be
> safely converted to the vector-element type.
> Consider the following code.
>
> @smallexample
> typedef int v4si __attribute__ ((vector_size (16)));
>
> v4si a, b, c;
>
