| Message ID | alpine.DEB.2.02.1210111104400.22783@stedding.saclay.inria.fr |
|---|---|
| State | New |
| Headers | show |
On Thu, Oct 11, 2012 at 11:25 AM, Marc Glisse <marc.glisse@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.glisse@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; >
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;