From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5829 invoked by alias); 11 Jun 2008 14:30:53 -0000 Received: (qmail 5817 invoked by uid 22791); 11 Jun 2008 14:30:52 -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; Wed, 11 Jun 2008 14:30:32 +0000 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id m5BEUE8C015153; Wed, 11 Jun 2008 15:30:15 +0100 Received: from smtp.corp.google.com (spacemonkey2.corp.google.com [192.168.120.114]) by zps78.corp.google.com with ESMTP id m5BEU9PD024065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jun 2008 07:30:12 -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 m5BETq2I016378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jun 2008 07:30:03 -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> From: Ian Lance Taylor Date: Wed, 11 Jun 2008 14:30:00 -0000 In-Reply-To: <484FD5B5.5040601@ispras.ru> (Andrey Belevantsev's message of "Wed\, 11 Jun 2008 17\:40\:05 +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/msg00686.txt.bz2 Andrey Belevantsev writes: > Ian Lance Taylor wrote: >> This looks wrong. I don't think you can call pass_compute_alignments >> after calling pass_free_cfg. > On ia64 we needed to compute alignments after the scheduling was done, > i.e. after pass_machine_reorg. Otherwise cfg changes messed up the > alignments, for example, loop label could move to the other basic > block. Of course, on ia64 there is a cfg at that point, and this is > why it's worked. I missed that it would not be like this for other > targets. What would you suggest doing instead? I would suggest that you have the ia64 machine_reorg pass call compute_alignments itself. Admittedly compute_alignments will be run twice for the ia64, but it should be a fairly fast pass--it loops through all the basic blocks, but not through all the insns. >> That said, I'm not sure I like insn_added very much. It seems like a >> relatively fragile hook, as it will be hard to detect cases when it is >> used incorrectly. Can you expand on why this is needed? For building >> data structures, why does it not suffice to use get_max_uid? What >> sorts of insns do you expect to see created here? > We have control over all insns we create in the scheduler, and we > properly initialize data for them, except for the jumps that get > created during e.g. redirect_edge_and_branch. The hook was invented > to catch these. We can probably do with e.g. memorizing get_max_uid > before and after the calls to cfgrtl functions and then passing the > new insns to the initialization engine, but we need an rtx there, not > an uid. How can we get it? Unfortunately, there is no mapping from the UID to the insn. I was thinking of, e.g., using the UID to scale array sizes. If you look at haifa-sched.c, you'll see that it uses calls like redirect_edge_succ, generates branch insns itself, and calls extend_global (a haifa-sched.c) function to build information about the insn. Is it reasonable for your code to work at that level? Since you have data about all insns, don't you also need data about insns which have changed or are deleted? Ian