From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15714 invoked by alias); 19 Jul 2011 21:59:25 -0000 Received: (qmail 15705 invoked by uid 22791); 19 Jul 2011 21:59:25 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,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, 19 Jul 2011 21:59:08 +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 p6JLwxE3012882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2011 17:58:59 -0400 Received: from anchor.twiddle.net (vpn-226-67.phx2.redhat.com [10.3.226.67]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6JLwwuU032499; Tue, 19 Jul 2011 17:58:59 -0400 Message-ID: <4E25FE22.5000804@redhat.com> Date: Tue, 19 Jul 2011 22:09:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bernd Schmidt CC: "gcc@gcc.gnu.org" Subject: Re: [RFC] Remove -freorder-blocks-and-partition References: <4E25F810.6050904@redhat.com> <4E25FA5E.9010303@codesourcery.com> In-Reply-To: <4E25FA5E.9010303@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00353.txt.bz2 On 07/19/2011 02:42 PM, Bernd Schmidt wrote: > On 07/19/11 23:33, Richard Henderson wrote: >> But after pass_partition_blocks, we run into trouble. There >> are no less than 4 other passes that add *new* crossing jumps >> without doing *any* of the subsequent fixups for less capable >> targets: pass_outof_cfg_layout_mode, pass_reorder_blocks, >> pass_sched2 (ia64 only? it's in code in haifa that looks like >> speculative load fixups), and pass_convert_to_eh_region_ranges. Unrelated to your response, I had intended to make the point that three of the errant passes above run after register allocation. Which of course does not work on any target that does not support long branches. > > Is it possible to leave it in for targets to call during their reorg > pass, which I'm assuming is late enough? Really the entire pass pipeline > after reload needs rethinking. I'm not sure how one would apply this during a reorg pass. Presumably your target does have at least long unconditional branches, since otherwise one runs into a register allocation problem. If in addition you've long unconditional branches as well as no exception_receiver pattern, then it seems like you could completely do away with the early pass_partition_blocks. Given the pre-conditions above, we could delay the assignment of blocks to partitions until quite late. Although you probably would never leave it any later than pass_reorder_blocks. r~