From patchwork Tue Jul 3 14:48:48 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 168836 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 CE7F82C00C6 for ; Wed, 4 Jul 2012 01:53:56 +1000 (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=1341935637; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=WUcOgg64zkfwJ2x2STuQ NtL4vQ0=; b=eAUl0pi/9iovmZDNrfH0M2ZGIZz/komdvLAYb12ZgzFAaeNEf0Kt 0lKwBWl/mWvfTRC6jnJFNO34gtThq0cc9Vzxga9aHg2UU2+bkFImsnFr1C2LKi1i 8KnXXyVsGJp7ILOgVUod4KW0bfAyYK+ThZ8JqN/vQ/KMxt+gPYNfSn4= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=Y2IaVncUK92hL/QM9xpPxS1wqO8fczK1JhY9IIIf0b7Uc+BP4TARPKP3q1qDMV 8SDDPrhueTpSegb4pW7j6aAb64Ip82CGp3WWUQJJVQHRiZBf0oomzOVIaQyqgKTN obHVi27AYPuGJjw/0/0r7m0OFr30bOzRtk8gDOEXhI37c=; Received: (qmail 30743 invoked by alias); 3 Jul 2012 15:53:52 -0000 Received: (qmail 30735 invoked by uid 22791); 3 Jul 2012 15:53:49 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS, T_RP_MATCHES_RCVD 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, 03 Jul 2012 15:53:33 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q63FrXAb025006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Jul 2012 11:53:33 -0400 Received: from [10.36.4.108] (vpn1-4-108.ams2.redhat.com [10.36.4.108]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q63FrV5c024127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 11:53:32 -0400 Message-ID: <4FF30650.7010500@redhat.com> Date: Tue, 03 Jul 2012 15:48:48 +0100 From: nick clifton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: DJ Delorie CC: gcc-patches@gcc.gnu.org Subject: Re: RFA: MEP: Fix use of delete_insn. References: <87d34isdvd.fsf@redhat.com> <201206291844.q5TIiQ61000833@greed.delorie.com> <4FF14BC5.9010003@redhat.com> <201207021737.q62Hbt8W011894@greed.delorie.com> In-Reply-To: <201207021737.q62Hbt8W011894@greed.delorie.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 Hi DJ, > My concern is more about calling NEXT_INSN on a deleted insn. If > that's guaranteed to be "reliable", I'm OK with it. > So pick whichever solution is more future-proof and go for it :-) OK, I have gone with the following. I have replaced NEXT_INSN with next_nonnote_nondebug_insn, so that we are sure that we are dealing with a valid potential insn for removal. We do not have to worry about calling this on a deleted insn because we know that delete_insn() will only be called on a single set insn, and that deleting it will only remove that insn and not any others that follow it. Whilst doing this I noticed that follow might be set incorrectly (to a debug insn), so I fixed that as well. Cheers Nick gcc/ChangeLog 2012-07-03 Nick Clifton * config/mep/mep.c (mep_reorg_regmove): Use next_nonnote_non_debug_insn to advance to the next insn. Do not expect delete_insn to return an rtx. (insn)); @@ -5096,7 +5096,7 @@ follow, where)) { count ++; - next = delete_insn (insn); + delete_insn (insn); if (dump_file) { fprintf (dump_file, "\n----- Success! new insn:\n\n"); Index: gcc/config/mep/mep.c =================================================================== --- gcc/config/mep/mep.c (revision 189193) +++ gcc/config/mep/mep.c (working copy) @@ -5022,7 +5022,7 @@ done = 1; for (insn = insns; insn; insn = next) { - next = NEXT_INSN (insn); + next = next_nonnote_nondebug_insn (insn); if (GET_CODE (insn) != INSN) continue; pat = PATTERN (insn); @@ -5035,7 +5035,7 @@ && find_regno_note (insn, REG_DEAD, REGNO (SET_SRC (pat))) && mep_compatible_reg_class (REGNO (SET_SRC (pat)), REGNO (SET_DEST (pat)))) { - follow = next_nonnote_insn (insn); + follow = next_nonnote_nondebug_insn (insn); if (dump_file) fprintf (dump_file, "superfluous moves: considering %d\n", INSN_UID