This is the mail archive of the gcc@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: [lto] function to DECL associations for WPA repackaging


Diego Novillo wrote:
On 2008-06-11, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:

my sense is not to associate put this directly in the cgraph but to keep it
as a side table that is indexed by something like the cgraph node id. The
reason for leaning in this direction is that "what happens in the cgraph
stays in the cgraph", and the infomation we are talking about here is is
only really useful for the whopr repackaging. This is why i have resisted
honza's wanting to associate other ipa local information in the cgraph.

What we need here is a per-function symbol table. I don't think I mind if we put it together with each cgraph node or in a separate symbol table section indexed by node id. Both seem reasonable. Though I'm curious why you think storing it in the cgraph node directly is not a good idea.

What each function needs to be write to this table is every symbol in
gimple_referenced_vars(fn) that is marked as is_global_var().

I suppose that this table only needs to have the references to the
table stored in DECL_SECTION on the output file.


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. We have talked about having a symbol table and i certainly agree that that would be useful. That was not how this was presented in the first email of this thread. It was cast as something to hold the global and static vars so that you could do a specific whopr task. To accomplish that particular task, the set of global and static vars does need to be accessible outside of the function body.

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, i.e. nothing escapes the function body for these to point to. Furthermore, you do not want to have these things lying around when you are trying to cherry pick because all of the local vars for all of the functions are going to be huge.

Given these problems, I think that it does not make sense to serialize a symbol table (from a time and space point of view), but to simply rebuild the symbol table for a function when you read in the function body. Of course if there is info that is lost by doing this, then this will have to be revisited. But given that gcc goes to trouble of deliberately flattening all of block structure in a function, i do not see that much will be lost by just recovering the info as you deserialize the body.

And so i stand behind my suggestion to do something ad hoc and not persistent for the global vars and types for whopr.

We have a pass that computes this info currently, the ipa_referenced vars,

You mean pass_ipa_reference()? But this is the pass that sets read/written attributes from file-globals isn't it?


Diego.


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