This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Random cleanups [4/4]: Streamlining streamer


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]