From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8370 invoked by alias); 17 Sep 2011 07:17:09 -0000 Received: (qmail 8362 invoked by uid 22791); 17 Sep 2011 07:17:07 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yi0-f47.google.com (HELO mail-yi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Sep 2011 07:16:53 +0000 Received: by yia27 with SMTP id 27so2609950yia.20 for ; Sat, 17 Sep 2011 00:16:52 -0700 (PDT) Received: by 10.100.16.7 with SMTP id 7mr188549anp.156.1316243811081; Sat, 17 Sep 2011 00:16:51 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id v16sm27669157anq.16.2011.09.17.00.16.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Sep 2011 00:16:50 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 66EFE170C2BC; Sat, 17 Sep 2011 16:46:43 +0930 (CST) Date: Sat, 17 Sep 2011 07:59:00 -0000 From: Alan Modra To: gcc-patches@gcc.gnu.org, Bernd Schmidt , David Edelsohn Subject: PowerPC shrink-wrap support 0 of 3 Message-ID: <20110917071643.GT10321@bubble.grove.modra.org> Mail-Followup-To: gcc-patches@gcc.gnu.org, Bernd Schmidt , David Edelsohn MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes 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 X-SW-Source: 2011-09/txt/msg01005.txt.bz2 This patch series adds shrink-wrap support for PowerPC. The patches are on top of Bernd's "Initial shrink-wrapping patch": http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02557.html, but with the tm.texi patch applied to tm.texi.in. Bootstrapped and regression tested powerpc64-linux all langs except ada, and spec CPU2006 tested. The spec results were a little disappointing as I expected to see some gains, but my baseline was a -O3 run and I suppose most of the shrink-wrap opportunities were lost to inlining. I deliberately omitted defining RETURN_ADDR_REGNUM for PowerPC as I don't see why it is necessary to treat LR any differently to other regs saved by the prologue. I believe code in requires_stack_frame_p CLEAR_HARD_REG_SET (hardregs); note_stores (PATTERN (insn), record_hard_reg_sets, &hardregs); if (hard_reg_set_intersect_p (hardregs, prologue_used)) return true; will correctly pick up any set of LR. If code in a function body sets LR without saving and restoring around the use, then the prologue must save LR, so LR will be in prologue_used. -- Alan Modra Australia Development Lab, IBM