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.
2012-10-11 Marc Glisse <[email protected]>
* 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 GlisseIndex: 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;
