From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97549 invoked by alias); 18 Aug 2015 14:15:48 -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 97532 invoked by uid 89); 18 Aug 2015 14:15:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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; Tue, 18 Aug 2015 14:15:46 +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-23-Z9maVjssS3mAIX2Ve9pOsQ-1; Tue, 18 Aug 2015 15:15:41 +0100 Received: from localhost ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2015 15:15:41 +0100 From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,David Sherwood , GCC Patches , richard.sandiford@arm.com Cc: David Sherwood , GCC Patches Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax* References: <000001d0d5b0$5da4dbb0$18ee9310$@arm.com> <000001d0d8cf$2fb42770$8f1c7650$@arm.com> <000001d0d9a6$1efdc350$5cf949f0$@arm.com> Date: Tue, 18 Aug 2015 14:20:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 18 Aug 2015 15:30:12 +0200") Message-ID: <87fv3gbs36.fsf@e105548-lin.cambridge.arm.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-MC-Unique: Z9maVjssS3mAIX2Ve9pOsQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-08/txt/msg01004.txt.bz2 Richard Biener writes: > On Tue, Aug 18, 2015 at 1:07 PM, David Sherwood = wrote: >>> On Mon, Aug 17, 2015 at 11:29 AM, David Sherwood >>> wrote: >>> > Hi Richard, >>> > >>> > Thanks for the reply. I'd chosen to add new expressions as this seeme= d more >>> > consistent with the existing MAX_EXPR and MIN_EXPR tree codes. In >>> > addition it >>> > would seem to provide more opportunities for optimisation than a >>> > target-specific >>> > builtin implementation would. I accept that optimisation opportunitie= s will >>> > be more limited for strict math compilation, but that it was still >>> > worth having >>> > them. Also, if we did map it to builtins then the scalar version woul= d go >>> > through the optabs and the vector version would go through the >>> > target's builtin >>> > expansion, which doesn't seem very consistent. >>> >>> On another note ISTR you can't associate STRICT_MIN/MAX_EXPR and thus >>> you can't vectorize anyway? (strict IEEE behavior is about NaNs, corre= ct?) >> I thought for this particular case associativity wasn't an issue? >> We're not doing any >> reductions here, just simply performing max/min operations on each >> pair of elements >> in the vectors. I thought for IEEE-compliant behaviour we just need to >> ensure that for >> each pair of elements if one element is a NaN we return the other one. > > Hmm, true. Ok, my comment still stands - I don't see that using a > tree code is the best thing to do here. You can add fmin/max optabs > and special expansion of BUILT_IN_FMIN/MAX and you can use a target > builtin for the vectorized variant. > > The reason I am pushing against a new tree code is that we'd have an > awful lot of similar codes when pushing other flag related IL > specialities to actual IL constructs. And we still need to find a > consistent way to do that. In this case though the new code is really the "native" min/max operation for fp, rather than some weird flag-dependent behaviour. Maybe it's a bit unfortunate that the non-strict min/max fp operation got mapped to the generic MIN_EXPR and MAX_EXPR when the non-strict version is really the flag-related modification. The STRICT_* prefix is forced by that and might make it seem like more of a special case than it really is. If you're still not convinced, how about an internal function instead of a built-in function, so that we can continue to use optabs for all cases? I'd really like to avoid forcing such a generic concept down to target-specific builtins with target-specific expansion code, especially when the same concept is exposed by target-independent code for scalars. TBH though I'm not sure why an internal_fn value (or a target-specific builtin enum value) is worse than a tree-code value, unless the limit of the tree_code bitfield is in sight (maybe it is). Thanks, Richard