From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19142 invoked by alias); 29 Feb 2016 14:58:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 19128 invoked by uid 89); 29 Feb 2016 14:58:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_50,MEDICAL_SUBJECT,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=sk:const_i, UD:vector.md, vector.md, vectormd X-HELO: e06smtp08.uk.ibm.com Received: from e06smtp08.uk.ibm.com (HELO e06smtp08.uk.ibm.com) (195.75.94.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 29 Feb 2016 14:58:02 +0000 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Feb 2016 14:57:59 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp08.uk.ibm.com (192.168.101.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 29 Feb 2016 14:57:57 -0000 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gcc-patches@gcc.gnu.org Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id C948617D805D for ; Mon, 29 Feb 2016 14:58:20 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u1TEvuL75112218 for ; Mon, 29 Feb 2016 14:57:56 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u1TEvuCb015488 for ; Mon, 29 Feb 2016 07:57:56 -0700 Received: from oc7340732750.ibm.com (dyn-9-152-213-148.boeblingen.de.ibm.com [9.152.213.148]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u1TEvuGp015480; Mon, 29 Feb 2016 07:57:56 -0700 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 61A92642; Mon, 29 Feb 2016 15:57:56 +0100 (CET) Subject: Re: [PATCH 7/9] S/390: Get rid of Y constraint in vector.md. To: krebbel@linux.vnet.ibm.com (Andreas Krebbel) Date: Mon, 29 Feb 2016 14:58:00 -0000 From: "Ulrich Weigand" Cc: gcc-patches@gcc.gnu.org In-Reply-To: <1456735599-21355-8-git-send-email-krebbel@linux.vnet.ibm.com> from "Andreas Krebbel" at Feb 29, 2016 09:46:37 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20160229145756.61A92642@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16022914-0033-0000-0000-000005FD65DA X-SW-Source: 2016-02/txt/msg01949.txt.bz2 Andreas Krebbel wrote: > +; vec_set is supposed to *modify* an existing vector so operand 0 is > +; duplicated as input operand. > +(define_expand "vec_set" > + [(set (match_operand:V 0 "register_operand" "") > + (unspec:V [(match_operand: 1 "general_operand" "") > + (match_operand:SI 2 "shift_count_or_setmem_operand" "") This is probably only cosmetic, but should we use nonmemory_operand here instead of shift_count_or_setmem_operand (just like everywhere else now)? > +(define_expand "vec_extract" > + [(set (match_operand: 0 "nonimmediate_operand" "") > + (unspec: [(match_operand:V 1 "register_operand" "") > + (match_operand:SI 2 "shift_count_or_setmem_operand" "")] Likewise. > +(define_insn "*vec_set_plus" > + [(set (match_operand:V 0 "register_operand" "=v") > + (unspec:V [(match_operand: 1 "general_operand" "d") > + (plus:SI (match_operand:SI 2 "register_operand" "a") > + (match_operand:SI 4 "const_int_operand" "n")) > + (match_operand:V 3 "register_operand" "0")] > + UNSPEC_VEC_SET))] > + "TARGET_VX" > + "vlvg\t%v0,%1,%4(%2)" > + [(set_attr "op_type" "VRS")]) Wouldn't it be better to use %Y4 instead of %4 here? Or does the middle-end guarantee that this is never out of range? > +(define_insn "*vec_extract_plus" > + [(set (match_operand: 0 "nonimmediate_operand" "=d,QR") > + (unspec: [(match_operand:V 1 "register_operand" "v, v") > + (plus:SI (match_operand:SI 2 "nonmemory_operand" "a, I") > + (match_operand:SI 3 "const_int_operand" "n, I"))] > + UNSPEC_VEC_EXTRACT))] > + "TARGET_VX" > + "@ > + vlgv\t%0,%v1,%3(%2) > + vste\t%v1,%0,%2" > + [(set_attr "op_type" "VRS,VRX")]) Likewise for %3. Also, the second alternative seems odd, it matches solely a PLUS of two CONST_INTs, which is not canonical RTL ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com