From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19271 invoked by alias); 20 Mar 2015 17:44:13 -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 19240 invoked by uid 89); 20 Mar 2015 17:44:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: e32.co.us.ibm.com Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 20 Mar 2015 17:44:11 +0000 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Mar 2015 11:44:09 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 20 Mar 2015 11:44:07 -0600 Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id D186F1FF0023 for ; Fri, 20 Mar 2015 11:35:17 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2KHhwQ930605546 for ; Fri, 20 Mar 2015 10:43:58 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2KHi5tH030730 for ; Fri, 20 Mar 2015 11:44:05 -0600 Received: from ibm-tiger.the-meissners.org (dhcp-9-32-77-111.usma.ibm.com [9.32.77.111]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t2KHi5lP030702; Fri, 20 Mar 2015 11:44:05 -0600 Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id C04AA43C94; Fri, 20 Mar 2015 13:44:04 -0400 (EDT) Date: Fri, 20 Mar 2015 17:44:00 -0000 From: Michael Meissner To: Richard Biener Cc: Michael Meissner , David Edelsohn , GCC Patches Subject: Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math Message-ID: <20150320174404.GA32645@ibm-tiger.the-meissners.org> Mail-Followup-To: Michael Meissner , Richard Biener , David Edelsohn , GCC Patches References: <20150305200638.GA3059@ibm-tiger.the-meissners.org> <20150311222120.GA16631@ibm-tiger.the-meissners.org> <20150312152952.GA11678@ibm-tiger.the-meissners.org> <20150317231840.GA24459@ibm-tiger.the-meissners.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15032017-0005-0000-0000-0000099746E2 X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01100.txt.bz2 On Wed, Mar 18, 2015 at 12:08:47PM +0100, Richard Biener wrote: > Did you double-check if there are any differences in generated code? > Esp. the SPEC INT benchmarks look odd - they don't contain any > FP code. SpecINT does contain some amount of floating point. Off the top of my head: 1) Bzip2 does a percentage calculation for fprintf; 2) Libquantum uses sin/cos (which the compiler optimizes to sincos) in the initial setup to set up the data. 3) I don't recall if the version of GCC used in Spec had switched over to using floating point for the register allocator or not. 4) Perlbench has a lot of code that does floating pointing point, but the main loop excerised in the Spec runs probably doesn't use FP. Sorry I couldn't respond earlier, the corporate IMAP email server was down for a period of time. Any way, I do see code changes. Before the fix was made, if you used -ffast-math, it kept the floating point constants around until reload. When reload could not find a reload to load the constant, it would push the constant to memory, and do validize_mem on the address. This created the sequence: addis 9,2,.LC0@toc@ha addi 9,9,.LC0@toc@l lfd 0,0(9) Because the address was a single register, it could also load the value into the traditional Altivec registers: addis 9,2,.LC0@toc@ha addi 9,9,.LC0@toc@l lxsdx 32,0(9) And in fact the register allocator seemed to prefer loading constants into the traditional Altivec registers instead of the traditional floating point registers. Once I made the change to force the constant to memory earlier, it would use normal addressing, and generate something like: addis 9,2,.LC0@toc@ha lfs 0,.LC0@toc@l(9) This meant that a lot of addi's are no longer generated, because the addi is folded into the lfs/lfd instruction. In addition, due to the VSX memory instructions being only register+register, whenever the code wanted to load floating point constants, it would prefer the traditional floating point registers which had register+offset addressing. This meant in turn, that any instruction that used a FP constant could potentially be changed from a VSX form (i.e. xsmuldp) into a traditional FP form (i.e. fmul) if all of the inputs and outputs were traditional floating point registers. Finally, I suspect pushing the address out earlier, means that it might be keeping the address live a little bit longer, which could change things if we are spilling GPRs. One of the things I am working on for GCC 6.0 is going back to reworking on the address support to do a better job with fusion, and I believe it will reduce the life time for some of these address temporaries. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797