From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2416 invoked by alias); 19 Nov 2012 07:53:23 -0000 Received: (qmail 2408 invoked by uid 22791); 19 Nov 2012 07:53:22 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_HF X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Nov 2012 07:53:15 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAJ7rEjb014286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Nov 2012 02:53:14 -0500 Received: from zalov.redhat.com (vpn1-4-174.ams2.redhat.com [10.36.4.174]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAJ7rCA6010951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 02:53:13 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qAJ7rBCX008783; Mon, 19 Nov 2012 08:53:11 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qAJ7rBmY008782; Mon, 19 Nov 2012 08:53:11 +0100 Date: Mon, 19 Nov 2012 07:53:00 -0000 From: Jakub Jelinek To: Richard Henderson Cc: gcc-patches@gcc.gnu.org, Jeff Law Subject: Re: Patch ping Message-ID: <20121119075311.GB2315@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20121116091036.GG1886@tucnak.redhat.com> <50A7E10C.6010408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A7E10C.6010408@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-11/txt/msg01534.txt.bz2 On Sat, Nov 17, 2012 at 11:10:04AM -0800, Richard Henderson wrote: > On 11/16/2012 01:10 AM, Jakub Jelinek wrote: > > Hi! > > > > - PR54921 invalidate sp in cselib on fp setter insn > > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02035.html > > (perhaps in light of PR54402 the single_succ (ENTRY_BLOCK_PTR) > > from the patch should be nuked) > > > + rtx expr = find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX); > > + if (expr) > > + pat = XEXP (expr, 0); > > + if (GET_CODE (pat) == SET > > + && SET_DEST (pat) == hard_frame_pointer_rtx) > > + cselib_invalidate_rtx (stack_pointer_rtx); > > + else if (GET_CODE (pat) == PARALLEL) > > This is only one possible way that FP can be set. > The others are with CFA_DEF_CFA or CFA_ADJUST_CFA. > > Given > > + && frame_pointer_needed > + && RTX_FRAME_RELATED_P (insn) > > is there any reason to do more than > > && modified_in_p (hard_frame_pointer_rtx, insn) > > ? I'd prefer to only invalidate the stack pointer on the first assignment to the hard pointer. If the cselib link between sp and hfp is already broken, invalidating sp will only result in worse code. Dunno if there are any targets that adjust the hard frame pointer after it has been set once or similar. Perhaps we could walk here CSELIB_VAL_PTR (hfpval)->locs here, and look if any rtls in there have find_base_term (x->loc) == find_base_term (stack_pointer_rtx), and only if yes, invalidate (and guard it by the modified_in_p test). BTW, var-tracking.c uses a similar test. Jakub