From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85032 invoked by alias); 2 Oct 2015 09:27:19 -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 85021 invoked by uid 89); 2 Oct 2015 09:27:18 -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_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 02 Oct 2015 09:27:17 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 2717EB1F87; Fri, 2 Oct 2015 09:27:16 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t929REPl009732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Oct 2015 05:27:15 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id t929RCiP022232; Fri, 2 Oct 2015 11:27:13 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id t929RBHB022231; Fri, 2 Oct 2015 11:27:11 +0200 Date: Fri, 02 Oct 2015 09:27:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: James Greenhalgh , GCC Patches Subject: Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y); Message-ID: <20151002092711.GF28276@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1443707835-6888-1-git-send-email-james.greenhalgh@arm.com> <20151001183643.GD28276@tucnak.redhat.com> <20151002090358.GE28276@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00179.txt.bz2 On Fri, Oct 02, 2015 at 11:10:58AM +0200, Richard Biener wrote: > > BTW, it seems wrf also in many places uses MAX > > or MIN (always in pairs), would that be also > > something to optimize? > > Hmm, we'll already CSE copysign so the question is how to optimize > tem1 = MAX ; tem2= MIN ; Turn them back into control-flow? > What would we like to end up with in assembly? This wasn't a well thought thing. Just that perhaps depending on how copysign is expanded we might merge that with the min/max somehow. > > Also, the x * copysign (1.0, y) in wrf is actually x * (1/12.) * copysign (1.0, y) > > (or similar - other constants), wouldn't it make more sense to optimize that > > as x * copysign (1/12., y) first (at least if we can reassociate)? > > Yeah, I think CST * copysign (CST, ...) should constant fold to > copysign (CST', ...) > if that's always valid. I don't think association comes into play > here but as always > you read the fine prints of the standard for FP optimziations... The reason talking about reassoc is that we might not necessarily see CST * copysign (CST, ...) in the IL, but something different: _2051 = __builtin_copysignf (1.0e+0, vel_2000); ... _2059 = _2051 * _2058; _2060 = _2059 * 1.666666753590106964111328125e-2; is before reassoc1 and _2051 = __builtin_copysignf (1.0e+0, vel_2000); ... _2047 = _2051 * 1.666666753590106964111328125e-2; _2060 = _2047 * _2058; is after reassoc1, so in this case reassoc1 worked fine, but in another spot I see _2968 = __builtin_copysignf (1.0e+0, vel_2943); ... _2973 = _2968 * _2972; _2974 = _2973 * 8.3333335816860198974609375e-2; before reassoc1 and _2968 = __builtin_copysignf (1.0e+0, vel_2943); ... _3008 = _2972 * 8.3333335816860198974609375e-2; _2974 = _3008 * _2968; after reassoc1, so clearly reassoc puts those two together only randomly. So, either we'd teach reassoc to prefer putting constant and copysign of constant together, or even perform this optimization, or the match.pd (or elsewhere) change would need additional smarts. Note, I won't have time to work on this in the near future (OpenMP work still on the plate), so if James (or anyone else?) has time for that, it would be greatly appreciated. Jakub