From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26445 invoked by alias); 8 Jul 2008 14:46:05 -0000 Received: (qmail 26433 invoked by uid 22791); 8 Jul 2008 14:46:02 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jul 2008 14:45:42 +0000 Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id m68EjYXv002550; Tue, 8 Jul 2008 15:45:35 +0100 Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by wpaz24.hot.corp.google.com with ESMTP id m68EjWOM005849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Jul 2008 07:45:33 -0700 Received: from localhost.localdomain.google.com (69-36-227-135.cust.layer42.net [69.36.227.135] (may be forged)) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id m68EjPlu005890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Jul 2008 07:45:28 -0700 To: Andrey Belevantsev Cc: GCC Patches , Jim Wilson , Vladimir Makarov Subject: Re: Selective scheduling pass - middle end changes [1/1] References: <4845522C.3010006@ispras.ru> <4845528D.6050302@ispras.ru> <484FD5B5.5040601@ispras.ru> <4864E4EA.2040006@ispras.ru> <48737AE3.3050109@ispras.ru> From: Ian Lance Taylor Date: Tue, 08 Jul 2008 15:29:00 -0000 In-Reply-To: <48737AE3.3050109@ispras.ru> (Andrey Belevantsev's message of "Tue\, 08 Jul 2008 18\:34\:11 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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 X-SW-Source: 2008-07/txt/msg00637.txt.bz2 Andrey Belevantsev writes: > Ian Lance Taylor wrote: >> Well, I'm uncomfortable with the idea of the hook. I wouldn't >> necessarily mind a complete hook interface. But the one you've >> implemented seems sort of ad hoc and easy to get wrong. We don't >> currently have any way for a pass to clearly track every change to the >> RTL insn stream. If we need that, I think we should do it for real. > I have looked closely at the places where jumps are generated by > cfgrtl.c. There are only two of them, one in > force_fallthru_and_redirect and one in try_redirect_by_replacing_jump, > and all our usage of split_edge and redirect_edge_and_branch leads to > these places. What if I add an interface for register/unregister a > hook that would notify of creating new jumps by those functions? This > way, the changes in the scheduler will be minimal, and the hook itself > would be much more safe. I can make it a general cfg hook if desired, > but I doubt that tree cfg or cfglayout will use it. I really think that Steven's suggestion of using cfglayout mode is correct. Ian