From patchwork Tue Dec 18 11:45:19 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 207081 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 505DD2C0079 for ; Tue, 18 Dec 2012 22:45:47 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1356435948; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=7n+WMIt+KFFdAxbyU51sXn7Qs0Y=; b=bqewHptHQqi3l9XvDpF9qdwG+S8N7u0XeI6jmhlMYXgNbUS1uQ4oaTauPvnz+m Y+l8NbvPzsHN6mCZt4G63AeDWM6l1NUpTcO6+nNH4uCNLC1Uutv9qrGeL9MK4qhS H2LUJ33iayMs20qv7sk/uaxN7VHsOHnpyBzXpFK1rLl/s= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=DR+sikIBS4wyMGQ60nHDTGIXMHReK69oU2L30y1Ypz1GfIE/GAG4vW+m0JzVE8 qy09XmXkBhKAxAqYOvMYVXP+/fHpyc9QyZYC1Q2w4Hp5fwfrNZQL06LEQxjorTS/ l2EcFHw6XqXWoxwu70PBBkqGl46SItzsrRuJ1GuVtoCkc=; Received: (qmail 26144 invoked by alias); 18 Dec 2012 11:45:39 -0000 Received: (qmail 26134 invoked by uid 22791); 18 Dec 2012 11:45:37 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Dec 2012 11:45:22 +0000 Received: by mail-we0-f179.google.com with SMTP id r6so242846wey.24 for ; Tue, 18 Dec 2012 03:45:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.82.170 with SMTP id j10mr3679139wiy.2.1355831119974; Tue, 18 Dec 2012 03:45:19 -0800 (PST) Received: by 10.194.179.130 with HTTP; Tue, 18 Dec 2012 03:45:19 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Dec 2012 12:45:19 +0100 Message-ID: Subject: Re: [patch] PR debug/53948 From: Richard Biener To: Steven Bosscher Cc: GCC Patches , jan.kratochvil@redhat.com X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Wed, Jul 18, 2012 at 7:46 PM, Steven Bosscher wrote: > Hello, > > This is my proposed fix for PR53948. We don't want to put user > variables in callee-clobbered registers, but obviously function > arguments are OK there. REG_USERVAR_P is set on PARM_DECLs and on user > variables, so it can't be used to distinguish between the two. > > As it turns out, I can hi-jack a bit for that: 'unchanging' (currently > incorrectly documented as used on REG) for a new macro > REG_FUNCTION_PARM_P. I found one obvious place where this bit can be > used instead of REG_USERVAR_P, and probably there are a few more > places where this is useful (TBD, I'm going to look at all places > where RTL code looks at tree's PARM_DECL later). > > Bootstrapped&tested on powerpc64-unknown-linux-gnu. > OK for trunk? Just being pointed back to this patch ... I wonder if simply looking at REG_EXPR of a REG_USERVAR_P reg and checking whether it's a PARM_DECL isn't good enough (and simpler)? I suppose the optabs.c change was the "real" fix, thus sth like (untested) Thanks, Richard. > Ciao! > Steven > > PR debug/53948 > * rtl.h (REG_FUNCTION_PARM_P): New flag on a REG. Re-use 'unchaning'. > * emit-rtl.c (mark_function_parm_reg): New function. > * function.c (assign_parm_setup_reg): Use mark_function_parm_reg > instead of mark_user_reg. > * combine.c (can_change_dest_mode): Preserve REG_FUNCTION_PARM_P. > * web.c (entry_register): Likewise. > * reload1.c (reload): Likewise. > * ira-emit.c (ira_create_new_reg): Likewise. > * reginfo.c (reg_scan_mark_refs): Likewise. > * optabs.c (emit_libcall_block_1): Use REG_FUNCTION_PARM_P instead > of REG_USERVAR_P. > * regstat.c (dump_reg_info): Print REG_FUNCTION_PARM_P. > * doc/rtl.texi (REG_FUNCTION_PARM_P): Document it. > ('unchanging' flag): Fix documentation. Index: gcc/optabs.c =================================================================== --- gcc/optabs.c (revision 194552) +++ gcc/optabs.c (working copy) @@ -3848,9 +3848,13 @@ emit_libcall_block_1 (rtx insns, rtx tar rtx final_dest = target; rtx next, last, insn; - /* If this is a reg with REG_USERVAR_P set, then it could possibly turn - into a MEM later. Protect the libcall block from this change. */ - if (! REG_P (target) || REG_USERVAR_P (target)) + /* If this is a parameter with REG_USERVAR_P set, then it could possibly turn + into a MEM later (e.g. if a REG_EQUIV note is attached to the insns that + sets the reg). Protect the libcall block from this change. */ + if (! REG_P (target) + || (REG_USERVAR_P (target) + && REG_EXPR (target) != NULL_TREE + && TREE_CODE (REG_EXPR (target)) == PARM_DECL)) target = gen_reg_rtx (GET_MODE (target)); /* If we're using non-call exceptions, a libcall corresponding to an