From patchwork Tue Dec 11 08:21:49 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 205137 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 9A0DB2C007A for ; Tue, 11 Dec 2012 19:22:09 +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=1355818930; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=84gxlpPVZgTdEy2AEpT4 2pGs6pM=; b=UReIPj9I/Cgx3sYfZ1xKe0iBKzaMRWh7lgeK3FFXf6hANoXPK6oL fIbnlhyHRXerf1m0iOaHMDEfKRlzqj7YXAmCxnRwMI5ECQfAeruFOi/QZ2r8yI3g 7rE5Gwu/55MlGPdyjLPn0AKBpeHtI3qoWC7fF4w6TjaBJFvFRtc668U= 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:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=xqVPpaMIwwMmjXTPqPRH0O+uiQHMERoxETPyJ3VTnLzCd1bf08MSM6oJPvicH9 JMlM3lf1eZkmDkpsmx5Ac7t3Lr5Lo+K+uW0TatOa36MsFryDHy4IZlD67y91gXxy YH/5iUOVG7fyb2gG58+IUzVVszLY93/5RhvZreCyQqoxw=; Received: (qmail 5773 invoked by alias); 11 Dec 2012 08:21:59 -0000 Received: (qmail 5759 invoked by uid 22791); 11 Dec 2012 08:21:58 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SPF_HELO_PASS 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; Tue, 11 Dec 2012 08:21:53 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBB8Lqts010177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Dec 2012 03:21:52 -0500 Received: from zalov.redhat.com (vpn1-7-17.ams2.redhat.com [10.36.7.17]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBB8Lo4f018736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Dec 2012 03:21:52 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qBB8Lom4021964; Tue, 11 Dec 2012 09:21:50 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qBB8LoxJ021963; Tue, 11 Dec 2012 09:21:50 +0100 Date: Tue, 11 Dec 2012 09:21:49 +0100 From: Jakub Jelinek To: Vladimir Makarov Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix DEBUG_INSN handling in lra-constraints (PR rtl-optimization/55193) Message-ID: <20121211082149.GM2315@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline 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-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! As the testcase in the PR (unfortunately only reproduceable after reverting some inlining patch, so not including that testcase in the patch) shows, loc_equivalence_change_p isn't good enough for debug_insns, when a REG is substituted for VOIDmode constant. In that case, the surrounding SUBREG (handled in loc_equivalence_change_p), but also other operations like ZERO_EXTEND/SIGN_EXTEND, ZERO_EXTRACT etc. need to be simplified while we still know the original mode, and perhaps several times, as SIGN_EXTEND might be in another ZERO_EXTEND etc. The best way to deal with that is simplify_replace_fn_rtx which is used in various other places in the compiler. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2012-12-11 Jakub Jelinek PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Jakub --- gcc/lra-constraints.c.jj 2012-12-10 08:42:40.000000000 +0100 +++ gcc/lra-constraints.c 2012-12-10 18:43:04.977277475 +0100 @@ -3186,6 +3186,21 @@ loc_equivalence_change_p (rtx *loc) return result; } +/* Similar to loc_equivalence_change_p, but for use as + simplify_replace_fn_rtx callback. */ +static rtx +loc_equivalence_callback (rtx loc, const_rtx, void *) +{ + if (!REG_P (loc)) + return NULL_RTX; + + rtx subst = get_equiv_substitution (loc); + if (subst != loc) + return subst; + + return NULL_RTX; +} + /* Maximum allowed number of constraint pass iterations after the last spill pass. It is for preventing LRA cycling in a bug case. */ #define MAX_CONSTRAINT_ITERATION_NUMBER 30 @@ -3422,11 +3437,17 @@ lra_constraints (bool first_p) /* We need to check equivalence in debug insn and change pseudo to the equivalent value if necessary. */ curr_id = lra_get_insn_recog_data (curr_insn); - if (bitmap_bit_p (&equiv_insn_bitmap, INSN_UID (curr_insn)) - && loc_equivalence_change_p (curr_id->operand_loc[0])) + if (bitmap_bit_p (&equiv_insn_bitmap, INSN_UID (curr_insn))) { - lra_update_insn_regno_info (curr_insn); - changed_p = true; + rtx old = *curr_id->operand_loc[0]; + *curr_id->operand_loc[0] + = simplify_replace_fn_rtx (old, NULL_RTX, + loc_equivalence_callback, NULL); + if (old != *curr_id->operand_loc[0]) + { + lra_update_insn_regno_info (curr_insn); + changed_p = true; + } } } else if (INSN_P (curr_insn))