From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26096 invoked by alias); 7 Nov 2014 10:09:23 -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 26086 invoked by uid 89); 7 Nov 2014 10:09:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Nov 2014 10:09:22 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Fri, 07 Nov 2014 10:09:19 +0000 Received: from [10.1.209.51] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2014 10:09:19 +0000 Message-ID: <545C9A4E.2010903@arm.com> Date: Fri, 07 Nov 2014 10:09:00 -0000 From: Alan Lawrence User-Agent: Thunderbird 2.0.0.24 (X11/20101213) MIME-Version: 1.0 To: Bill Schmidt CC: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH 10/11][RS6000] Migrate reduction optabs to reduc_..._scal References: <544A3E0B.2000803@arm.com> <544A40D1.1040605@arm.com> <1415037053.3389.36.camel@gnopaine> <545BA564.6080200@arm.com> <1415300196.18771.32.camel@gnopaine> In-Reply-To: <1415300196.18771.32.camel@gnopaine> X-MC-Unique: 114110710091903401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00595.txt.bz2 Ah I see now! Thank you for explaining that bit, I was a bit puzzled when I= saw=20 it, but it makes sense now! Cheers, Alan Bill Schmidt wrote: > On Thu, 2014-11-06 at 16:44 +0000, Alan Lawrence wrote: >> Hmmm. I am a little surprised by your mention of "saturation points" as = I would=20 >> not expect any variety of reduc_plus to be a saturating operation??? >=20 > I wouldn't either, but the underlying vsum4ubs and vsum4sbs instructions > used in these patterns do both a reduction and an add to another value. > If that other value is large enough this can trigger a saturation event. > However, the patterns use vzero for this other value, so it's not > possible to approach the saturation cutoff for either instruction since > the reductions are being done on byte values. (Each word in the vector > result is the sum of the corresponding four byte values in the vector > source, added to the other value, which here is zero.) >=20 > Thanks, > Bill