From patchwork Mon Mar 5 22:34:07 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 144786 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 61DB6B6FA1 for ; Tue, 6 Mar 2012 09:34:56 +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=1331591699; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=9M/CP+t8OccT+g8w8b4gTrxfJzs=; b=ET3aTotV7ToHwGI 51os2igEDR+MfZ58ON6i+a0Rc6/scW41tLAgoHTD5Wyu7aa2TtQNpFnQ2fEBBlbb 2KlJpKdjtgH+1U0AMF+KELDdGE/eroZJe84dy9S7OAJGprlLzOxIxpEyvgSwg9Nq XkzTSkQrg+s86BCdl2QydkP1nVm8= 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:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=e/kMWgOtiYhQklxNBlB7SDsRLK62+L10WYUhOnDEJGnX74+Exwo8CU5Zp2ECfG lwS/rtvDkRnyZ7hUDF8uDfT+GlTFtCtTx2dIVtmE7GGPDCfa3eI8GI+LbNdbYCH8 C5BaU9E4mE7zHl+XS9CAAENrkMHXO2kiawxVILrt74EfQ=; Received: (qmail 5368 invoked by alias); 5 Mar 2012 22:34:52 -0000 Received: (qmail 5109 invoked by uid 22791); 5 Mar 2012 22:34:50 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL, BAYES_00, FROM_12LTRDOM, SUBJ_OBFU_PUNCT_FEW X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Mar 2012 22:34:31 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1S4gUA-0003IX-7n from Bernd_Schmidt@mentor.com ; Mon, 05 Mar 2012 14:34:30 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 14:33:33 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Mon, 5 Mar 2012 22:34:28 +0000 Message-ID: <4F553F5F.3020901@codesourcery.com> Date: Mon, 5 Mar 2012 23:34:07 +0100 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110920 Lightning/1.0b3pre Thunderbird/3.1.12 MIME-Version: 1.0 To: GCC Patches CC: Richard Kenner Subject: Delete dead (?) code in expand_expr_real_2 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 I found a weird piece of code that was added by kenner in a really early revision. It checks for VAR_DECLs with frame or stack pointers as DECL_RTL, and the comment in front of it mentions strength reduction. Presumably this was for the old loop optimizer? I can't think of anything that would require this in a modern version of gcc. Bootstrapped and tested on i686-linux; no changes in code generation on any of my test files. Ok? Bernd * expr.c (expand_expr_real_2) [PLUS_EXPR]: Delete code dealing with VAR_DECLs of frame or stack pointers. Index: gcc/expr.c =================================================================== --- gcc/expr.c (revision 184790) +++ gcc/expr.c (working copy) @@ -8040,30 +8040,6 @@ expand_expr_real_2 (sepops ops, rtx targ fold_convert_loc (loc, ssizetype, treeop1)); case PLUS_EXPR: - /* If we are adding a constant, a VAR_DECL that is sp, fp, or ap, and - something else, make sure we add the register to the constant and - then to the other thing. This case can occur during strength - reduction and doing it this way will produce better code if the - frame pointer or argument pointer is eliminated. - - fold-const.c will ensure that the constant is always in the inner - PLUS_EXPR, so the only case we need to do anything about is if - sp, ap, or fp is our second argument, in which case we must swap - the innermost first argument and our second argument. */ - - if (TREE_CODE (treeop0) == PLUS_EXPR - && TREE_CODE (TREE_OPERAND (treeop0, 1)) == INTEGER_CST - && TREE_CODE (treeop1) == VAR_DECL - && (DECL_RTL (treeop1) == frame_pointer_rtx - || DECL_RTL (treeop1) == stack_pointer_rtx - || DECL_RTL (treeop1) == arg_pointer_rtx)) - { - tree t = treeop1; - - treeop1 = TREE_OPERAND (treeop0, 0); - TREE_OPERAND (treeop0, 0) = t; - } - /* If the result is to be ptr_mode and we are adding an integer to something, we might be forming a constant. So try to use plus_constant. If it produces a sum and we can't accept it,