Random cleanups [4/4]: Streamlining streamer

[Richard Guenther]

On Thu, Mar 31, 2011 at 4:07 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> I fear I wasn't as thorough in also splitting this one into several
> patches, but the different cleanups are at least mostly in different
> files.  They are:
>
> * lto-lang remembers all builtin decls in a local list, to be returned
>  by the getdecls langhook.  But as we have our own write_globals langhook
>  this isn't actually called (except by dbxout.c), so there's no point in
>  remembering.
>
> * lto.c:lto_materialize_function has code to read in the function body
>  sections, do something with them in non-wpa mode, and discard them then.
>  There's no point in even reading them in in non-wpa mode (except for a
>  dubious error message that rather is worth an assert).
>
> * gimple.c:gimple_type_leader_entry is a fixed length cache for speeding
>  up our type merging machinery.  It can hold references to many meanwhile
>  merged trees, interferring with the wish of free up much memory with a
>  ggc_collect with early-merging LTO.  We can simply make it deletable.
>
> * ipa-inline.c: some tidying in not calling a macro with function call
>  arguments, and calling a costly function only after early-outs.
>
> * lto-streamer-out.c : it writes out and compares strings character by
>  character.  memcmp and output_data_stream work just as well
>
> * lto-streamer: output_unreferenced_globals writes out all global varpool
>  decls.  The reading side simply reads over all of them, and ignores
>  them.  This was supposed to help symbol resolution, and it probably once
>  did.  But since some time we properly emit varpool and cgraph nodes, and
>  references between them, and a proper symtab.  There's no need for
>  emitting these trees again.
>
> * lto-streamer: the following changes the bytecode:
>  1: all indices  into the cache are unsigned, hence we should say
>     so, instead of casting casts back and forth
>  2: trees are only appended to the cache, when writing out.  When reading
>     in we read in all trees in the stream one after the other, also
>     appending to the cache.  References to existing trees _always_ are to
>     - well - existing trees, hence to those already emitted earlier in
>     the stream, i.e. with a smaller offset, and more importantly with a
>     known index even at reader side.
>
>     So, the offset never is used, so remove that and all associated
>     tracking and params.
>  3: for the same reason we also don't need to stream the index that new
>     trees get in the cache.  They will get exactly the ones they also had
>     when writing out.  We could use it as consistency check, but we
>     stream the expected tree-node for back-references for that already.
>
>     Obviously we do need to stream the index in back references (aka
>     pickled references).
>
>     (the index could change if there's a different set of nodes preloaded
>     into the cache between writing out and reading in.  But that would
>     have much worse problems already, silently overwriting slots with
>     trees from the stream; we should do away with the preloaded nodes,
>     and instead rely on type merging to get canonical versions of the
>     builtin trees)
>
> Not streaming offset and index for most trees obviously shortens the
> bytecode somewhat but I don't have statistics on how much.  Not much would
> be my guess.
>
> Regstrapped on x86_64-linux with the other three cleanups.  Okay for
> trunk?

I don't see a need (in this patch) to move lto_input_chain earlier, but
I suppose it doesn't matter and is needed by a followup.

Ok.

Thanks,
Richard.