From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126023 invoked by alias); 19 Aug 2015 09:36:29 -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 126002 invoked by uid 89); 19 Aug 2015 09:36:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f172.google.com Received: from mail-ig0-f172.google.com (HELO mail-ig0-f172.google.com) (209.85.213.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 19 Aug 2015 09:36:27 +0000 Received: by igui7 with SMTP id i7so103493495igu.1 for ; Wed, 19 Aug 2015 02:36:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.78.133 with SMTP id b5mr682496igx.32.1439976985410; Wed, 19 Aug 2015 02:36:25 -0700 (PDT) Received: by 10.107.32.140 with HTTP; Wed, 19 Aug 2015 02:36:25 -0700 (PDT) In-Reply-To: <87fv3gbs36.fsf@e105548-lin.cambridge.arm.com> References: <000001d0d5b0$5da4dbb0$18ee9310$@arm.com> <000001d0d8cf$2fb42770$8f1c7650$@arm.com> <000001d0d9a6$1efdc350$5cf949f0$@arm.com> <87fv3gbs36.fsf@e105548-lin.cambridge.arm.com> Date: Wed, 19 Aug 2015 09:48:00 -0000 Message-ID: Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax* From: Richard Biener To: Richard Biener , David Sherwood , GCC Patches , richard.sandiford@arm.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01053.txt.bz2 On Tue, Aug 18, 2015 at 4:15 PM, Richard Sandiford wrote: > 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 seemed 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 opportunities 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 would 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, correct?) >>> 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. In some sense. But the "strict" version already has a builtin (just no special expander in builtins.c). We usually don't add 1:1 tree codes for existing builtins (why have builtins at all then?). > 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. The target builtin is for the vectorized variant - not all targets might have that and we'd need to query the target about this. So using a IFN would mean adding a target hook for that query. > 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). I think tree_code is 64bits now. Richard. > Thanks, > Richard >