From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20026 invoked by alias); 9 May 2014 02:41:07 -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 20004 invoked by uid 89); 9 May 2014 02:41:04 -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-f51.google.com Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 09 May 2014 02:41:02 +0000 Received: by mail-pa0-f51.google.com with SMTP id kq14so3653517pab.24 for ; Thu, 08 May 2014 19:41:00 -0700 (PDT) X-Received: by 10.66.136.103 with SMTP id pz7mr14861044pab.140.1399603260345; Thu, 08 May 2014 19:41:00 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id io8sm4489532pbc.96.2014.05.08.19.40.57 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 May 2014 19:40:59 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id E4891EA017A; Fri, 9 May 2014 12:10:54 +0930 (CST) Date: Fri, 09 May 2014 02:41:00 -0000 From: Alan Modra To: David Edelsohn Cc: GCC Patches Subject: Re: [RS6000] Fix PR61098, Poor code setting count register Message-ID: <20140509024054.GE5162@bubble.grove.modra.org> Mail-Followup-To: David Edelsohn , GCC Patches References: <20140508014846.GA5162@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00545.txt.bz2 On Thu, May 08, 2014 at 09:48:35AM -0400, David Edelsohn wrote: > The history is 32 bit HWI. Right. > The ChangeLog does not mention the changes to rs6000.md nor rs6000-protos.h. Oops, added. * config/rs6000/rs6000.md (movsi_internal1_single+1): Update call to rs6000_emit_set_const in splitter. (movdi_internal64+2, +3): Likewise. * config/rs6000/rs6000-protos.h (rs6000_emit_set_const): Update prototype. > Please do not remove all of the comments from the two functions. The > comments should provide some documentation about the different > purposes of the two functions other than setting DEST to a CONST. I believe my updated comment covers the complete purpose of the function nowadays. The comments I removed are out-dated, and should have been removed a long time ago.. rs6000_emit_set_const does not even look at N, it always returns a non-zero result, and the return is only tested for non-zero. I removed MODE too, because that is always the same as GET_MODE (dest). > Why did you remove the test for NULL dest? > > - if (dest == NULL) > - dest = gen_reg_rtx (mode); > > That could occur, at least it used to occur. I'm sure we can't get a NULL dest nowadays. All (three) uses of rs6000_emit_set_const occur in splitters. They all must have passed a gpc_reg_operand constraint on operands[0] before calling rs6000_emit_set_const, so if NULL were possible we'd segfault in gpc_reg_operand. > I think that the way you rearranged the invocations of copy_rtx() in > rs6000_emit_set_long_const() is okay, but it would be good for someone > else to double check. Yeah, that function is a bit messy. I took the approach of always use a bare "dest" once in the last instruction emitted, with every other use getting hit with copy_rtx. The previous approach was similar, but used the bare "dest" on the first instruction emitted. Obviously you don't need copy_rtx anywhere with the new code when can_create_pseudo_p is true, but I felt it wasn't worth optimising that for the added source complication. -- Alan Modra Australia Development Lab, IBM