[lto] function to DECL associations for WPA repackaging

[Kenneth Zadeck]

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