From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29519 invoked by alias); 11 May 2014 23:39:36 -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 29504 invoked by uid 89); 11 May 2014 23:39:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 11 May 2014 23:39:33 +0000 Received: by mail-pa0-f44.google.com with SMTP id ld10so7014056pab.31 for ; Sun, 11 May 2014 16:39:31 -0700 (PDT) X-Received: by 10.67.13.226 with SMTP id fb2mr48127685pad.146.1399851570382; Sun, 11 May 2014 16:39:30 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id bs17sm40748972pac.28.2014.05.11.16.39.28 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 May 2014 16:39:29 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id D59B7EA017A; Mon, 12 May 2014 09:09:23 +0930 (CST) Date: Sun, 11 May 2014 23:39:00 -0000 From: Alan Modra To: David Edelsohn , GCC Patches Subject: Re: [RS6000] Fix PR61098, Poor code setting count register Message-ID: <20140511233923.GI5162@bubble.grove.modra.org> Mail-Followup-To: David Edelsohn , GCC Patches References: <20140508014846.GA5162@bubble.grove.modra.org> <20140509024054.GE5162@bubble.grove.modra.org> <20140511225316.GH5162@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140511225316.GH5162@bubble.grove.modra.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00722.txt.bz2 On Mon, May 12, 2014 at 08:23:16AM +0930, Alan Modra wrote: > On Sat, May 10, 2014 at 10:24:34PM -0400, David Edelsohn wrote: > > On Thu, May 8, 2014 at 10:40 PM, Alan Modra wrote: > > > rs6000_emit_set_const ... always returns a non-zero result ... > > > > Can you help clarify the removal of the code that tests if the > > splitter failed? > > See above. On thinking some more, let me retract the patch for the time being. While it's true that I was only removing dead code in the splitters, the question of why this code has become dead is worth looking into. I suspect a previous patch to rs6000_emit_set_const was wrong, and that we should in fact be failing before reload (but never after), when an expansion would take too many instructions. "Too many" being a sequence that is slower than loading a 64-bit constant from the TOC. We try to make that sort of tradeoff in rs6000_emit_move (see num_insn_constant call), but that is really too early. Some manipulations of code modify constants. I've seen cases where rs6000_emit_move decided to inline a constant, but later changes to the value meant the expansion was five instructions. -- Alan Modra Australia Development Lab, IBM