From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21361 invoked by alias); 22 Sep 2014 13:27:14 -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 21352 invoked by uid 89); 22 Sep 2014 13:27:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e35.co.us.ibm.com Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 22 Sep 2014 13:27:11 +0000 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 22 Sep 2014 07:27:09 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 22 Sep 2014 07:27:08 -0600 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 4E55619D803E for ; Mon, 22 Sep 2014 07:15:52 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s8MDR75f49348614 for ; Mon, 22 Sep 2014 15:27:07 +0200 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s8MDR6kN023395 for ; Mon, 22 Sep 2014 07:27:07 -0600 Received: from [9.65.81.153] (sig-9-65-81-153.mts.ibm.com [9.65.81.153]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s8MDR5oV023233; Mon, 22 Sep 2014 07:27:05 -0600 Message-ID: <1411392424.2935.23.camel@gnopaine> Subject: Re: [PATCH 12/14][Vectorizer] Redefine VEC_RSHIFT_EXPR and vec_shr_optab as endianness-neutral From: Bill Schmidt To: Alan Lawrence Cc: David Edelsohn , "gcc-patches@gcc.gnu.org" , Aldy Hernandez , Steve Ellcey , Eric Christopher Date: Mon, 22 Sep 2014 13:27:00 -0000 In-Reply-To: References: <541AC4D2.9040901@arm.com> <541AD353.6020405@arm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14092213-6688-0000-0000-000005006AFE X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg01813.txt.bz2 On Thu, 2014-09-18 at 09:12 -0400, David Edelsohn wrote: > On Thu, Sep 18, 2014 at 8:42 AM, Alan Lawrence wrote: > > The direction of VEC_RSHIFT_EXPR has been endian-dependent, contrary to the > > general principles of tree. This patch updates fold-const and the vectorizer > > (the only place where such expressions are created), such that > > VEC_RSHIFT_EXPR always shifts towards element 0. > > > > The tree code still maps directly onto the vec_shr_optab, and so this patch > > *will break any bigendian platform defining the vec_shr optab*. > > --> For AArch64_be, patch follows next in series; > > --> For PowerPC, I think patch/rfc 15 should fix, please inspect; > > --> For MIPS, I think patch/rfc 16 should fix, please inspect. > > > > gcc/ChangeLog: > > > > * fold-const.c (const_binop): VEC_RSHIFT_EXPR always shifts towards > > element 0. > > > > * tree-vect-loop.c (vect_create_epilog_for_reduction): always > > extract > > the result of a reduction with vector shifts from element 0. > > > > * tree.def (VEC_RSHIFT_EXPR, VEC_LSHIFT_EXPR): Comment shift > > direction. > > > > * doc/md.texi (vec_shr_m, vec_shl_m): Document shift direction. > > > > Testing Done: > > > > Bootstrap and check-gcc on x86_64-none-linux-gnu; check-gcc on > > aarch64-none-elf. > > Why wasn't this tested on the PowerLinux system in the GCC Compile Farm? > > Also, Bill Schmidt can help check the PPC parts fo the patches. Sorry for the late response; I just returned from vacation. I think that patch 15 looks reasonable on the surface, but would be more comfortable if it had been tested. I would echo David's suggestion that you please test this on gcc110 in the compile farm to avoid surprises. Given the similarity between vec_shl_ and vec_shr_ I am ok with removing the former; it won't be difficult to re-create it later if needed. Please add some of the language you used above about VEC_RSHIFT_EXPR as commentary for vec_shr_ in vector.md, as right-shifting towards element zero is not an obvious concept on a BE machine. Thanks, Bill > > Thanks, David >