From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5013 invoked by alias); 16 Nov 2005 22:42:39 -0000 Received: (qmail 5005 invoked by uid 22791); 16 Nov 2005 22:42:36 -0000 Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 16 Nov 2005 22:42:36 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-04.spheriq.net with ESMTP id jAGMgXi4015412 for ; Wed, 16 Nov 2005 22:42:33 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-03.spheriq.net with ESMTP id jAGMgWXp028366 for ; Wed, 16 Nov 2005 22:42:32 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id jAGMgWH3011693 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 16 Nov 2005 22:42:32 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 62401DA41; Wed, 16 Nov 2005 22:42:31 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id C6D3047594; Wed, 16 Nov 2005 22:45:29 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6FA3975969; Wed, 16 Nov 2005 22:45:29 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B82774750E; Wed, 16 Nov 2005 22:45:28 +0000 (GMT) Received: from st.com (linsvr9.bri.st.com [164.129.13.87]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGZ40452 (AUTH "joern rennecke"); Wed, 16 Nov 2005 22:42:28 GMT Message-ID: <437BB5D4.4060702@st.com> Date: Wed, 16 Nov 2005 22:42:00 -0000 From: Joern RENNECKE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Jeffrey A Law Cc: Steven Bosscher , gcc@gcc.gnu.org Subject: Re: Delay branch scheduling vs. the CFG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.1.07 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2005-11/txt/msg00737.txt.bz2 > > > 4. An entirely new basic block on its own. > > > > When can option 4 happen?? > IIRC it occurs when there was only 1 insn in either the target > or fall-thru block. When it gets sucked into the delay > slot of a branch, then it is effectively its own basic > block. When the fall-through is ended by a code label, and has only one insn, and that is eligible for a delay-slot which can be annulled-true, the fall-through block can end up in the delay slot. When the target block is ended by an unconditional jump, and otherwise has only one insn, which is elegible for a delay slot in preceding branch that can be anulled-false, the fall-through block can end up in the delay slot. Likwise if the fall-through block consists only of a branch-delay-slot eligible insn and an unconditional jump, the branch and fall-through block can be converted into an inverted branch with anulled-false delay slot insn. And finally, sometimes earlier reorg changes have changed the data flow so that actually no anulled slots are required (if there were no changes before, jump optimization should have caught these opportunities, placing the lone insn in front of the branch); or the only data anti-dependency might have the branch condition itself.