From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1823 invoked by alias); 30 Jun 2008 16:13:21 -0000 Received: (qmail 1813 invoked by uid 22791); 30 Jun 2008 16:13:21 -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; Mon, 30 Jun 2008 16:12:31 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id m5UGCN6R001071; Mon, 30 Jun 2008 17:12:24 +0100 Received: from smtp.corp.google.com (spacemonkey2.corp.google.com [192.168.120.114]) by zps36.corp.google.com with ESMTP id m5UGCMFq007003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jun 2008 09:12:23 -0700 Received: from localhost.localdomain.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id m5UGCIbh023867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jun 2008 09:12:19 -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> From: Ian Lance Taylor Date: Mon, 30 Jun 2008 16:16:00 -0000 In-Reply-To: <4864E4EA.2040006@ispras.ru> (Andrey Belevantsev's message of "Fri\, 27 Jun 2008 17\:02\:34 +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-06/txt/msg01952.txt.bz2 Andrey Belevantsev writes: > If you're uncomfortable with the idea of the hook, I can invent > something along the lines of searching the new jumps in the code and > passing them to the initialization routines. This would effectively > find insns given their UIDs and the knowledge that they has got > created somewhere near the given point in the CFG. I think this will > not happen too often to have significant effects on compile time. The > hook seemed to be just the simpler way of doing this. 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. Ian