From: Michael Matz <matz@suse.de>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Richard Guenther <rguenther@suse.de>,
"H.J. Lu" <hjl.tools@gmail.com>,
gcc-patches@gcc.gnu.org, dnovillo@google.com, jakub@redhat.com
Subject: Re: varpool alias reorg
Date: Mon, 27 Jun 2011 16:22:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1106271801000.17115@wotan.suse.de> (raw)
In-Reply-To: <20110627154815.GB23824@kam.mff.cuni.cz>
Hi,
On Mon, 27 Jun 2011, Jan Hubicka wrote:
> > I still like to stream unmodified builtins as builtins, as that is
> > similar to pre-loading the streamer caches with things like
> > void_type_node or sizetype.
>
> Doing so will need us to solve the other one decl rules probly. I didn't
> really got what the preloading is useful for after all?
One important thing that really affects correctness which preloading does
is to guarantee pointer equality for things like void_type_node or
error_mark_node, which are used sometimes. If we weren't doing preloading
we would have to forcibly merge all these trees over different units, and
what's worse, also fill out the global tree arrays with that merged
variant. And for that we'd need to note somehow which array slot a
certain tree is coming from (and deal with the fact that different
language frontends fill this array differently, sometimes with
pointer-eqal tree nodes, sometimes only with semantically equal tree
nodes, sometimes not at all).
Or we could fix all places where we use pointer equality with some of the
global trees, which I wouldn't like, even for abstract considerations.
There's really no point in having different but equal void_type nodes, or
error_mark nodes.
preloading really is the easiest way to solve all this. It's just
important that all .o files have the same idea about "tree at slot
so-and-so" (e.g. meaning "error_mark_node"), which I fixed some weeks ago.
And with early-debug-info we don't even then have the issue of e.g. the
base integer types not being named like the frontend emitted them.
Ciao,
Michael.
next prev parent reply other threads:[~2011-06-27 16:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-18 9:11 Jan Hubicka
2011-06-18 14:49 ` H.J. Lu
2011-06-23 14:34 ` H.J. Lu
2011-06-23 16:44 ` Jan Hubicka
2011-06-24 12:30 ` Jan Hubicka
2011-06-24 12:33 ` Jan Hubicka
2011-06-27 14:08 ` Richard Guenther
2011-06-27 16:13 ` Jan Hubicka
2011-06-27 16:22 ` Michael Matz [this message]
2011-06-28 8:34 ` Richard Guenther
2011-06-27 9:43 ` Richard Guenther
2011-06-27 9:50 ` Jan Hubicka
2011-06-22 8:17 ` Regression with "varpool alias reorg" Hans-Peter Nilsson
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=Pine.LNX.4.64.1106271801000.17115@wotan.suse.de \
--to=matz@suse.de \
--cc=dnovillo@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=hubicka@ucw.cz \
--cc=jakub@redhat.com \
--cc=rguenther@suse.de \
/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).