Re: [pph] Adapting LTO streaming for front end AST saving

[Jan Hubicka <hubicka@ucw.cz>]

> 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.