Diego Novillo wrote:
On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:

 I think that if you want to cast this as we need to have a symbol table for
the compiler in general then that is fine.

Yes, but we only need a symbol table for globals.  Temporaries and
locals need not be in this table.

 However, there are specific/peculiar problems with serializing the
function's symbol table outside of the function body itself.  There will be
no "there there" for the local variables and types

This table should not have local variables in it.  Only those globals
referenced by the function body.


So then there are two issues here:

1) Is there any use for such a table outside of whopr? If so, then this should be part of the cgraph. If not, then it should just be something that is created by the serializer, and dumped out and reconstituted by the cherry picker.

2) there is the issue that richi pointed out on irc:

[07:46]    <zadeck>    richi: i am now confused by this email thread
[07:46]    <richi>    zadeck: I am confused as well
[07:47]    <richi>    zadeck: why does referenced_vars not fit your needs?
[07:47]    <zadeck>    this is the problem with delayed communications.
[07:47]    <zadeck>    see my last email.
[07:48]    <richi>    oh, new mail again!
[07:48]    <richi>    ;)
[07:49] <richi> zadeck: ok, the problem is that you cannot re-build the global vars part
[07:49]    <richi>    at de-serializing time
[07:50]    <zadeck>    i do not understand why you cannot
[07:50]    <richi>    or do you serialize globals as varpool nodes as well?
[07:50]    -->|    manphiz ([EMAIL PROTECTED]) has joined #gcc
[07:50]    <richi>    consider foo = &bar; bar = &foobar; x () { x = foo; }
[07:50]    <richi>    how, looking at x(), can you reach foobar?
[07:51] <richi> find_referenced_vars() puts that in the functions referenced_vars list of x [07:51] <richi> because optimization passes might substitute these constant addresses walking the initializers [07:52] <richi> (of course I have no idea how you serialize/deserialize global vars with an initializer ;))
[07:54]    <zadeck>    but that is only true if foo and bar are const
[07:54]    <zadeck>    and static
[07:54]    <richi>    or are marked const by ipa_reference
[07:54]    <richi>    sure
[07:55]    <richi>    but in some way we need to deal with this
[07:57] <zadeck> i see this issue, but the problem is that we cannot serialize the local vars outside of the function body.

I have no idea how to make sure, in whopr, that function x sees foobar if you are going to cherry pick the globals also.

Diego.

Reply via email to