From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9056 invoked by alias); 23 Mar 2011 16:39:13 -0000 Received: (qmail 8916 invoked by uid 22791); 23 Mar 2011 16:39:11 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Mar 2011 16:39:05 +0000 Received: from eggs.gnu.org ([140.186.70.92]:40742) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Q2R5M-0007D0-Dk for gcc@gnu.org; Wed, 23 Mar 2011 12:39:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2R5L-0005Ve-5U for gcc@gnu.org; Wed, 23 Mar 2011 12:39:04 -0400 Received: from ksp.mff.cuni.cz ([195.113.26.206]:32977 helo=atrey.karlin.mff.cuni.cz) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2R5K-0005UP-Vy for gcc@gnu.org; Wed, 23 Mar 2011 12:39:03 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 23159F0692; Wed, 23 Mar 2011 17:38:59 +0100 (CET) Date: Wed, 23 Mar 2011 16:39:00 -0000 From: Jan Hubicka To: Richard Guenther Cc: Diego Novillo , gcc@gnu.org, Jan Hubicka , Lawrence Crowl Subject: Re: [pph] Adapting LTO streaming for front end AST saving Message-ID: <20110323163858.GA13705@atrey.karlin.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 195.113.26.206 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-03/txt/msg00357.txt.bz2 > On Wed, 23 Mar 2011, Diego Novillo wrote: > > > Over at the PPH branch we are starting to re-use the LTO streaming > > routines to save front end trees. Clearly, there are things that need > > to be extended and/or replaced since LTO streaming assumes that we are > > in GIMPLE. However, there is a large intersection that I think can be > > commoned out. > > > > - ASTs do not need to concern themselves with language differences. > > They are generated and consumed by cc1plus, so saving > > language-dependent information is fine. > > - LTO streaming has several checks and assumptions that prevent > > non-gimple trees (e.g., DECL_SAVED_TREE must be NULL). > > > > I'm looking for opinions on what would be the best approach to factor > > out the common code. So far, I have created a layer of routines and > > data structures that the front end calls to manipulate PPH files. > > These are wrappers on top of LTO streaming that deal with all the > > sections, buffers and streams used by LTO. > > > > I was thinking of using langhooks to do things like checks (like the > > check for DECL_SAVED_TREE in > > lto_output_ts_decl_non_common_tree_pointers or the asserts in > > lto_get_common_nodes). I'm expecting that there will be other things, > > like handling more tree nodes in the tree streaming routines. But > > everything else seems to be already sufficiently flexible for our > > needs. > > > > Thoughts? > > Yes, Micha has a load of patches cleaning up streaming and removing > unecessary abstraction. So, why'd you need to share any of it? I Cool, I also have some. > think it would be much easier if you worked with a copy (ugh, > streaming trees again....). I also think using same machinery for FE/gimple is a mistake. Trees are making life hard since they are interface in between FE<->gimplifier, part of gimple, interface for RTL expansion and way we represent debug info. Those are not neccesarily related things and tying them together makes things harder to optimize & cleanup. I would rather see well define Gimple bitcode rather than designing common format to handle PCHs, LTO and external templates on the top of existing trees. Honza > > Richard.