From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3729 invoked by alias); 23 Mar 2011 14:53:44 -0000 Received: (qmail 3507 invoked by uid 22791); 23 Mar 2011 14:53:42 -0000 X-SWARE-Spam-Status: No, hits=-3.4 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 14:53:32 +0000 Received: from eggs.gnu.org ([140.186.70.92]:37451) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Q2PRD-0000cl-8t for gcc@gnu.org; Wed, 23 Mar 2011 10:53:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2PRB-0005d9-HI for gcc@gnu.org; Wed, 23 Mar 2011 10:53:31 -0400 Received: from cantor.suse.de ([195.135.220.2]:37563 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2PRB-0005bD-C8 for gcc@gnu.org; Wed, 23 Mar 2011 10:53:29 -0400 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id D77D490975; Wed, 23 Mar 2011 15:53:22 +0100 (CET) Date: Wed, 23 Mar 2011 14:53:00 -0000 From: Richard Guenther To: Diego Novillo Cc: gcc@gnu.org, Jan Hubicka , Lawrence Crowl Subject: Re: [pph] Adapting LTO streaming for front end AST saving In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-Received-From: 195.135.220.2 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/msg00355.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 think it would be much easier if you worked with a copy (ugh, streaming trees again....). Richard.