public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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.

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