From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3736 invoked by alias); 5 Apr 2012 15:23:41 -0000 Received: (qmail 3726 invoked by uid 22791); 5 Apr 2012 15:23:40 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Apr 2012 15:23:27 +0000 Received: by ggcy3 with SMTP id y3so785172ggc.20 for ; Thu, 05 Apr 2012 08:23:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Om4l4s85PrtVna/LhR5iNQksTtLfGds+j8wuf8woUaw=; b=Ab8rqwUvkljLd4Bu+E16IcOdWOU0aIxjkq6COMEGXYPxR+EIDk2ks/xcM2TwOHbHDO 6DD3YsRurmL/c/B2ZYQGkHZyIgXiKYsoxW2OvsF+iDHXC8we50c/PQ2RoITkbzcMjmQZ 0J1c4Ak1VhkFXnsaoXGbJ5/CnrE8uZ4e588GNMcJbhJ0uns1V6am9s0twTh2DJr0oasA 8zO4SlraJNvl4qGhjw/9jjZKBfoZfNyGZtliCp1mn6UnccvlD5upGXQuORzJtQ+oj7ZK 6jpCnpuPJq5+JxZq6g6ZpopmKYw28OwabGxvYOOhEt4hXZSypeJFXs0ll8cnz3kAqEPU Oc+g== Received: by 10.236.173.130 with SMTP id v2mr2497538yhl.98.1333639406603; Thu, 05 Apr 2012 08:23:26 -0700 (PDT) Received: by 10.236.173.130 with SMTP id v2mr2497518yhl.98.1333639406428; Thu, 05 Apr 2012 08:23:26 -0700 (PDT) Received: from dnovillo-macbookpro.local ([72.14.228.1]) by mx.google.com with ESMTPS id e45sm16224169yhk.2.2012.04.05.08.23.24 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:23:25 -0700 (PDT) Message-ID: <4F7DB8EA.5040601@google.com> Date: Thu, 05 Apr 2012 15:23:00 -0000 From: Diego Novillo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Richard Guenther CC: gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PATCH][1/n] Cleanup global pass execution flow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlvRfsAjy5OR2sWGqEKK0eXyfX8/2DuOymN9GC2kaPw93Tv3PEOy/wmx1CyxM40blpCZMpBzA+6gu+q/+4CO5R9K6zO0MqAoOz4iNQaBwQdKuCM8ZJ7tGrsVhpb+Z36KjP9TTdBzhqz+1UNRdqMzpP6xOv677/jTrhimZ7pXo19zh957x0= 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: 2012-04/txt/msg00295.txt.bz2 On 4/5/12 9:54 AM, Richard Guenther wrote: > Honza, does this look ok? I am going to continue this way > until I can re-architect the toplevel pass structure in a way > that we hand control more to the pass manager. Well, hopefully ;) Related to this, have you thought about the handoff points between front ends and the middle end? In LTO (and at some point in the gimple front end branch) we have all this code setting up various tidbits like: - Creating cgraph nodes. - Creating FUNCTION_DECLs - Setting their gimple bodies - Etc. It would be nice if front ends had a single handoff point into the middle-end. So, for instance, if the FE only needed to call cgraph_create_node() or varpool_node() to register new functions and globals. After doing all that registration, the FE calls cgraph_optimize() (or some other unique entry point). I *think* this is roughly how things work, but there seem to be various other cgraph/middle-end calls made from front ends. Diego.