From patchwork Thu Oct 11 09:25:01 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Glisse X-Patchwork-Id: 190840 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id C39C52C008C for ; Thu, 11 Oct 2012 20:25:20 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1350552321; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Date:From:To:Subject:Message-ID:User-Agent:MIME-Version: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=gA/53jG biiz6NI7m6mpDcpb9n0Q=; b=NH6o+Bu2X1eMyC3SUv2rSymO/z01OCltKrcSelS 2v78iyKpvePcxxRFMjkPsRNT82dYdcteN/FdrgbZ0Qq4ncLBPWIFYLiwpa4PBAHP bv+Zgcj5AZ3Wvu4Z0mT4wJg3L1KpTXdMsbrmEtl4xb140u/23dz7JvAJa++lkZFN feKM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Date:From:To:Subject:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=PSiv3j8A4s0Eh62K+m1Yv7sSk0iO3WZrJ56yPEhwPkYbOCbzOM6ovoke6QdHEp q5Qbju7AXoyp5KaQfFl4fwFi6w7GkKvdq7PX8RxNdm1MCiKAgFQglcqL3q4iqL/1 32UJK4QHTCzS5uAqgBrKSmfANJL5V52KIhLuNVCa3wWlc=; Received: (qmail 21204 invoked by alias); 11 Oct 2012 09:25:10 -0000 Received: (qmail 21183 invoked by uid 22791); 11 Oct 2012 09:25:09 -0000 X-SWARE-Spam-Status: No, hits=-8.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail4-relais-sop.national.inria.fr (HELO mail4-relais-sop.national.inria.fr) (192.134.164.105) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Oct 2012 09:25:03 +0000 Received: from stedding.saclay.inria.fr ([193.55.250.194]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 Oct 2012 11:25:01 +0200 Received: from glisse (helo=localhost) by stedding.saclay.inria.fr with local-esmtp (Exim 4.80) (envelope-from ) id 1TMF0n-0005yk-KQ for gcc-patches@gcc.gnu.org; Thu, 11 Oct 2012 11:25:01 +0200 Date: Thu, 11 Oct 2012 11:25:01 +0200 (CEST) From: Marc Glisse To: gcc-patches@gcc.gnu.org Subject: [doc] Vector operations Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org 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 * 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. 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;