This is the mail archive of the 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]

Re: [doc] Vector operations

On Thu, Oct 11, 2012 at 11:25 AM, Marc Glisse <> 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.


Many thanks,

> 2012-10-11  Marc Glisse  <>
>         * doc/extend.texi (Vector Extensions): C++ improvements.
>         * doc/generic.texi (LSHIFT_EXPR, RSHIFT_EXPR): Mixed vector-scalar.
>         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.
> @@ -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.
>  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.
>  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 Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]