This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Biener <richard dot guenther at gmail dot com>*To*: Marc Glisse <marc dot glisse at inria dot fr>*Cc*: gcc-patches at gcc dot gnu dot org*Date*: Thu, 11 Oct 2012 16:35:58 +0200*Subject*: Re: [doc] Vector operations*References*: <alpine.DEB.2.02.1210111104400.22783@stedding.saclay.inria.fr>

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; >

**References**:**[doc] Vector operations***From:*Marc Glisse

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |