From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1719 invoked by alias); 24 Oct 2014 12:01:17 -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 1709 invoked by uid 89); 24 Oct 2014 12:01:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 12:01:15 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id ADE5CAAF3; Fri, 24 Oct 2014 12:01:12 +0000 (UTC) Date: Fri, 24 Oct 2014 12:01:00 -0000 From: Richard Biener To: Alan Lawrence cc: "gcc-patches@gcc.gnu.org" , David Edelsohn Subject: Re: [PATCH v2 0-6/11] Fix PR/61114, make direct vector reductions endianness-neutral In-Reply-To: <544A3E0B.2000803@arm.com> Message-ID: References: <544A3E0B.2000803@arm.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2014-10/txt/msg02539.txt.bz2 On Fri, 24 Oct 2014, Alan Lawrence wrote: > This is the first half of my previous patch series > (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01456.html), that is the part > making the REDUC_..._EXPR tree codes endian-neutral, and adding a new > reduce-to-scalar optab in place of the endianness-dependent > reduc_[us](plus|min|max)_optab. > > I'm leaving the vec_shr portion out of this patch series, as the link between > the two halves is only the end goal of removing an "if (BYTES_BIG_ENDIAN)" > from tree-vect-loop.c; this series removes that from one code path so can > stand alone. > > Patches 1-6 are as previously posted apart from rebasing and removing the > old/poisoned AArch64 patterns as per maintainer's request. Patches 1, 2, 4, 5 > and 6 have already been approved; patch 3 was discussed somewhat but I think > we decided against most of the ideas raised, I have added comment to > scalar_reduc_to_vector. I now reread Richie's "Otherwise the patch looks good > to me" and wonder if I should have taken that as an approval but I didn't read > it that way at the time...??? Yes, it was an approval ;) > Patches 7-11 migrate migrate ARM, x86, IA64 (I think), and mostly PowerPC, to > the new reduc_(plus|[us](min|max))_scal_optab. I have not managed to work out > how to do the same for MIPS (specifically what I need to add to > mips_expand_vec_reduc), and have had no response from the maintainers, so am > leaving that for now. Also I haven't migrated (or worked out how to target) > rs6000/paired.md, help would be most welcome. > > > The suggestion was then to "complete" the migration, by removing the old > optabs. There are a few options here and I'll follow up with appropriate > patches according to feedback received. I see options: > > (1) just delete the old optabs (and the migration code). This would > performance-regress the MIPS backend, but should not break it, although one > should really do *something* with the then-unused > reduc_[us](plus|min|max)_optab in config/mips/loongson.md. > > (2) also renaming reduc_..._scal_optab back to reduc_..._optab; would break > the MIPS backend if something were not done with it's existing patterns. > > (2a) Alternatively I could just use a different new name, e.g. reduce_...., > reduct_...., vec_reduc_..., anything that's less of a mouthful than > reduc_..._scal. Whilst being only-very-slightly-different from the current > reduc_... might be confusing, so might changing the meaning of the optab, and > its signature, with the existing name, so am open to suggestions? I definitely prefer (2). Thanks, Richard.