From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69830 invoked by alias); 1 Jul 2015 13:52:29 -0000 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 Received: (qmail 69818 invoked by uid 89); 1 Jul 2015 13:52:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Jul 2015 13:52:26 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZAIR3-0001tz-SI from Bernd_Schmidt@mentor.com ; Wed, 01 Jul 2015 06:52:22 -0700 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.3.224.2; Wed, 1 Jul 2015 14:52:20 +0100 Message-ID: <5593F08D.6090107@codesourcery.com> Date: Wed, 01 Jul 2015 13:52:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Chen Gang , Jeff Law , Richard Henderson , CC: gcc-patches List Subject: Re: [PATCH] config/bfin/bfin.c (hwloop_optimize): Use return false instead of gcc_assert for checking jump_insn. References: <5591A09A.5050903@codesourcery.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000301020807000408040502" X-SW-Source: 2015-07/txt/msg00052.txt.bz2 --------------000301020807000408040502 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-length: 746 On 07/01/2015 03:04 AM, Chen Gang wrote: > For me, the more details are: > > - The insns have 2 loops which can be lsetup optimized. > > - After hwloop_optimize finishes 1st lsetup optimization, it generates > new lsetup insn which appends to jump insn in the basic block (which > causes the insns are not 'standard' but OK for code generation). The problem is that you can't append anything to a basic block after a jump. You need to create a new one. This problem doesn't usually show up since nothing ever looks at the basic block again, unless both directions from the conditional branch happen to branch to lsetup candidate loops. Below is a patch. Can you test this with anything you have beyond the testsuite? Bernd --------------000301020807000408040502 Content-Type: text/x-patch; name="bblsetup.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bblsetup.diff" Content-length: 707 diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c index 8c1e18a..2c6f195 100644 --- a/gcc/config/bfin/bfin.c +++ b/gcc/config/bfin/bfin.c @@ -3796,8 +3796,19 @@ hwloop_optimize (hwloop_info loop) { gcc_assert (JUMP_P (prev)); prev = PREV_INSN (prev); + emit_insn_after (seq, prev); + } + else + { + emit_insn_after (seq, prev); + BB_END (loop->incoming_src) = prev; + basic_block new_bb = create_basic_block (seq, seq_end, + loop->head->prev_bb); + edge e = loop->incoming->last (); + gcc_assert (e->flags & EDGE_FALLTHRU); + redirect_edge_succ (e, new_bb); + make_edge (new_bb, loop->head, 0); } - emit_insn_after (seq, prev); } else { --------------000301020807000408040502--