From: Richard Guenther <rguenther@suse.de>
To: Diego Novillo <dnovillo@google.com>
Cc: reply@codereview.appspotmail.com, Jan Hubicka <jh@suse.cz>,
gcc-patches@gcc.gnu.org
Subject: Re: [lto] Merge streamer hooks from pph branch. (issue4568043)
Date: Mon, 06 Jun 2011 14:51:00 -0000 [thread overview]
Message-ID: <alpine.LNX.2.00.1106061640120.810@zhemvz.fhfr.qr> (raw)
In-Reply-To: <BANLkTik8dVqMM4CZCz8mB49CcAiMAO33uA@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 9909 bytes --]
On Sat, 4 Jun 2011, Diego Novillo wrote:
> On Wed, Jun 1, 2011 at 15:19, Richard Guenther <rguenther@suse.de> wrote:
>
> > Yes, I see no benefit of using a global function to get access
> > to the address of a global variable.
>
> There is the minor benefit of being able to control access to it, but
> I don't have a really convincing reason to give you, so I changed it
> to a global.
Thanks. It feels more consistent this way.
> >> >> + Â Â if (h->indexable_with_decls_p && h->indexable_with_decls_p (expr))
> >> >> + Â Â Â {
> >> >> + Â Â Â Â output_record_start (ob, LTO_global_decl_ref);
> >> >> + Â Â Â Â lto_output_var_decl_index (ob->decl_state, ob->main_stream, expr);
> >> >
> >> > Why hook it this way and not
> >> >
> >> > Â Â Â Â Â Â if (h->output_tree_ref
> >> > Â Â Â Â Â Â Â Â && h->output_tree_ref (...))
> >> > Â Â Â Â Â Â Â break;
> >> > Â Â Â Â Â Â gcc_unreachable ();
> >> >
> >> > I find the flag vs. function hook stuff somewhat odd.
> >>
> >> Sure. Â It's
> >
> > ... missing words? ;)
>
> Sorry. I meant to continue with "It's just that this particular hook
> is simpler if it only needs to decide whether the node can be written
> as a decl reference. The code to write the node will be the same
> everywhere." It would lead to duplication and the hooks would need to
> know more internal details of the generic streamer (they need to write
> the reference in exactly the way that lto_input_tree is expecting).
>
> This is not a flag, actually. It's a predicate function called on a
> node. If the node passes the predicate, then it is written in the
> decl index table.
Hm, ok.
>
> >> >> @@ -1438,8 +1450,27 @@ lto_output_tree (struct output_block *ob, tree expr, bool ref_p)
> >> >> Â Â Â to be materialized by the reader (to implement TYPE_CACHED_VALUES). Â */
> >> >> Â Â if (TREE_CODE (expr) == INTEGER_CST)
> >> >> Â Â Â {
> >> >> - Â Â Â lto_output_integer_cst (ob, expr, ref_p);
> >> >> - Â Â Â return;
> >> >> + Â Â Â bool is_special;
> >> >> +
> >> >> + Â Â /* There are some constants that are special to the streamer
> >> >> + Â Â (e.g., void_zero_node, truthvalue_false_node).
> >> >> + Â Â These constants cannot be rematerialized with
> >> >> + Â Â build_int_cst_wide because they may actually lack a type (like
> >> >> + Â Â void_zero_node) and they need to be pointer-identical to trees
> >> >> + Â Â materialized by the compiler tables like global_trees or
> >> >> + Â Â c_global_trees.
> >> >> +
> >> >> + Â Â If the streamer told us that it has special constants, they
> >> >> + Â Â will be preloaded in the streamer cache. Â If we find a match,
> >> >> + Â Â then stream the constant as a reference so the reader can
> >> >> + Â Â re-materialize it from the cache. Â */
> >> >> + Â Â Â is_special = streamer_hooks ()->has_unique_integer_csts_p
> >> >> + Â Â Â Â Â Â Â Â && lto_streamer_cache_lookup (ob->writer_cache, expr, NULL);
> >> >> + Â Â Â if (!is_special)
> >> >> + Â Â {
> >> >> + Â Â Â lto_output_integer_cst (ob, expr, ref_p);
> >> >> + Â Â Â return;
> >> >> + Â Â }
> >> >
> >> > ??? Â We should not arrive here for such global trees. Â Please do not
> >> > merge this part of the patch as part of the hook introducing (keep
> >> > patches simple, make them do a single thing ...)
> >>
> >> Not sure what you are objecting to. Â We do execute this for global
> >> trees in the C++ FE (as described in the comment). Â Are you objecting
> >> to never handling unique constants or to merging this handling until
> >> the pph bits are in?
> >
> > Are you not pre-loading those global trees then?
>
> I am, but since the streamer always wanted to stream INTEGER_CSTs
> separately, it wasn't getting a chance to check the cache first.
>
> > Yes, I think this isn't the time to merge this piece.
>
> No problem. I'll keep this part in the branch.
>
> >Â Ah, I think I get it - we don't stream integer constants as trees.
>
> Right.
>
> > But it's odd that you only handle this
> > for integer-csts and not other trees we don't stream as-is (and
> > thus do not enter into the cache)
>
> Because constants are the only ones that are handled right before the
> cache is consulted. Every other pre-built tree can be cached
> (regardless of whether it's handled by the streamer).
>
> > - I think this should be moved up a level and made generic to handle all trees. Â Or we should
> > handle integer-csts similar to builtins - always enter them in the cache,
>
> I tried this, but the result was sub-optimal
> (http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00563.html)
> Putting constants in the cache, caused various failures which I never
> fully debugged because I noticed an increase in the object size (I
> remember it was noticeable, but not by how much).
>
> I didn't insist too much with this approach, so maybe I could try it again.
>
>
> > or only handle all pre-loaded nodes that way.
>
> That is what we do. Pre-loaded nodes always go through the cache.
> The problem were pre-loaded constants, since they *never* go through
> the cache.
Do you remember if it was only void_zero_node that causes problems?
We could just special-case it in
lto_input_integer_cst/lto_output_integer_cst. Or even fix the C family
frontends to not create or use this strange node. It seems to be
a special tree for "empty valid something" which could as well be
a new tree code with a singleton object.
> >> >> @@ -2238,6 +2269,8 @@ static void
> >> >> Â lto_writer_init (void)
> >> >> Â {
> >> >> Â Â lto_streamer_init ();
> >> >> + Â if (streamer_hooks ()->writer_init)
> >> >> + Â Â streamer_hooks ()->writer_init ();
> >> >
> >> > This hook should always exist. Â Why is this called in a context with
> >> > lto_*?
> >>
> >> There is common streaming code that both the gimple and c++ streamers
> >> use. Â I suppose both could call lto_streamer_init and then call their
> >> own initializer routines instead of doing a hook.
> >
> > Yeah, I'd prefer that. Â I don't have a clear picture yet on what
> > piece of the streamer is actually shared.
>
> Sure. Done.
>
> >> >> +
> >> >> +/* Initialize all the streamer hooks used for streaming GIMPLE. Â */
> >> >> +
> >> >> +void
> >> >> +gimple_streamer_hooks_init (void)
> >> >
> >> > It's more like lto_streamer_hooks_init, no? Â You are basically
> >> > turning lto_streamer_* to tree_streamer_* and make lto_streamer_*
> >> > tree_streamer_* + lto_streamer_hooks, no?
> >>
> >> I was about to call them gimple_streamer_hooks, but lto_streamer_hooks
> >> is also fine with me. Â Subsequent patch. Â So:
> >>
> >> 1- Call the generic implementation and streamer hooks tree_streamer_*
> >> 2- Rename the lto-specific parts of streaming to lto_streamer_*
> >> 3- Move generic streaming implementation to tree-streamer.[ch]
> >>
> >> Does that sound OK?
> >
> > That sounds ok. Â You are only sharing the code streaming trees, right?
>
> Right. Patch coming up on top of the revised patch for streamer hooks.
>
> The attached revision of the patch has been tested again with an LTO
> profiledbootstrap on x86_64. OK for trunk?
Looks good to me.
Thanks,
Richard.
> * Makefile.in (lto-compress.o): Add dependency on LTO_STREAMER_H.
> (cgraph.o): Likewise.
> (cgraphunit.o): Likewise.
> * cgraphunit.c: Include lto-streamer.h
> (cgraph_finalize_compilation_unit): Call lto_streamer_hooks_init
> if LTO is enabled.
> * lto-streamer-in.c (unpack_value_fields): Call
> streamer_hooks.unpack_value_fields if set.
> (lto_materialize_tree): For unhandled nodes, first try to
> call lto_streamer_hooks.alloc_tree, if it exists.
> (lto_input_ts_decl_common_tree_pointers): Move reading of
> DECL_INITIAL to lto_streamer_read_tree.
> (lto_read_tree): Call lto_streamer_hooks.read_tree if set.
> (lto_streamer_read_tree): New.
> (lto_reader_init): Rename from lto_init_reader.
> Move initialization code to lto/lto.c.
> * lto-streamer-out.c (pack_value_fields): Call
> streamer_hooks.pack_value_fields if set.
> (lto_output_tree_ref): For tree nodes that are not
> normally indexable, call streamer_hooks.indexable_with_decls_p
> before giving up.
> (lto_output_ts_decl_common_tree_pointers): Move handling
> for FUNCTION_DECL and TRANSLATION_UNIT_DECL to
> lto_streamer_write_tree.
> (lto_output_tree_header): Call streamer_hooks.is_streamable
> instead of lto_is_streamable.
> Call lto_streamer_hooks.output_tree_header if set.
> (lto_write_tree): Call lto_streamer_hooks.write_tree if
> set.
> (lto_streamer_write_tree): New.
> (lto_output): Call lto_streamer_init directly.
> (lto_writer_init): Remove.
> * lto-streamer.c (streamer_hooks): New.
> (lto_streamer_cache_create): Call streamer_hooks.preload_common_nodes
> instead of lto_preload_common_nodes.
> (lto_is_streamable): Move from lto-streamer.h
> (lto_streamer_hooks_init): New.
> (streamer_hooks): New.
> (streamer_hooks_init): New.
> * lto-streamer.h (struct output_block): Forward declare.
> (struct lto_input_block): Likewise.
> (struct data_in): Likewise.
> (struct bitpack_d): Likewise.
> (struct streamer_hooks): Declare.
> (streamer_hooks): Declare.
> (lto_streamer_hooks_init): Declare.
> (lto_streamer_write_tree): Declare.
> (lto_streamer_read_tree): Declare.
> (streamer_hooks_init): Declare.
> (lto_is_streamable): Move to lto-streamer.c
>
> lto/ChangeLog
>
> * lto.c (lto_init): New.
> (lto_main): Call it.
>
>
> Diego.
>
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
next prev parent reply other threads:[~2011-06-06 14:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-01 0:13 Diego Novillo
2011-06-01 12:08 ` Richard Guenther
2011-06-01 16:03 ` Diego Novillo
2011-06-01 19:19 ` Richard Guenther
2011-06-04 19:30 ` Diego Novillo
2011-06-06 14:51 ` Richard Guenther [this message]
2011-06-06 15:33 ` Diego Novillo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1106061640120.810@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=dnovillo@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=reply@codereview.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).