From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12391 invoked by alias); 18 Sep 2015 15:39:56 -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 12380 invoked by uid 89); 18 Sep 2015 15:39:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Sep 2015 15:39:55 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-19-AqA6jC1uQums2jVNZ_SBwg-1; Fri, 18 Sep 2015 16:39:51 +0100 Received: from e105915-lin.cambridge.arm.com ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2015 16:39:50 +0100 Subject: Re: [PATCH, rs6000] Add expansions for min/max vector reductions To: Richard Biener , Bill Schmidt References: <1442413689.2896.45.camel@gnopaine> <55F98AD2.4080408@arm.com> <1442419857.10907.0.camel@gnopaine> <55F9A0D8.3020900@arm.com> <1442499522.10907.25.camel@gnopaine> <1442507190.10907.30.camel@gnopaine> Cc: "gcc-patches@gcc.gnu.org" , "dje.gcc@gmail.com" , Alan Hayward , "ramana.gcc@googlemail.com" From: Alan Lawrence Message-ID: <55FC3046.6070303@arm.com> Date: Fri, 18 Sep 2015 15:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: X-MC-Unique: AqA6jC1uQums2jVNZ_SBwg-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01432.txt.bz2 On 18/09/15 09:35, Richard Biener wrote: > > Btw, we ditched the original reduce-to-vector variant due to its > endianess issues (it only had _one_ element of the vector contain > the reduction result). Re-introducing reduce-to-vector but with > the reduction result in all elements wouldn't have any issue like > that. > > Of course it would introduce a third optab variant similar to the > old (now legacy) version but with different semantics... I am working (again) on finishing this migration, and think I have fixed th= e=20 endianness issues on PowerPC, patch posted just now. MIPS/Loongson, I'm st= ill=20 struggling with; AFAICT, they implement their own reduc_ pattern for most c= ases,=20 which for the most part repeats the midend's approach using shifts, but the= =20 first step uses a funky permute, as they have a faster instruction for this= ... --Alan