[lto] function to DECL associations for WPA repackaging

[Kenneth Zadeck]

Richard Guenther wrote:
> On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <aaw@google.com> wrote:
>   
>> Doug,
>>
>> Yesterday, we spoke briefly about the need to efficiently determine
>> the DECL's required by each function.  Here's a more detailed
>> overview.  During the WPA phase of WHOPR, we will be reading in a
>> collection of object files, performing analysis on call-graph/summary
>> data, and outputting repackaged object files.  This is described more
>> fully in the "Repackaging" section at
>> http://gcc.gnu.org/wiki/whopr/wpa.  During a first implementation, the
>> output files are likely to mirror the input files with inlinable
>> function bodies appended.  As our WPA implementation gets more
>> sophisticated, we will likely want to support more complex repackaging
>> schemes based on call-graph partitioning.
>>
>> In either case, we need a way to efficiently determine which DECL's
>> must accompany a given set of function bodies.  DECL references are
>> currently stored as integral indexes within the serialized function
>> bodies.  These need to be reproduced elsewhere.  Right now, I'm
>> thinking the call-graph nodes are the best place for this.  Kenny
>> might have some suggestions on this front.
>>
>> In the end, WPA should look something like this:
>>
>> 1) Read in call-graph nodes, DECL's, and summary data from the input files.
>> 2) Do some analysis.  Partition the functions described in the call-graph nodes.
>> 3) Scan each partition's call graph to determine which DECL's are needed.
>> 4) Write each partition's function bodies, DECL's, and call-graph
>> nodes to an output file.
>>
>> If you could work on the DECL association logic, that would be greatly
>> appreciated.
>>     
>
> We have gimple_referenced_vars (cfun), which is a hashtable mapping the
> DECL_UID of every referenced variable in the function to its DECL.  In the
> end this could be serialized as a bitmap of DECL_UIDs if you can associate
> DECL_UIDs with the proper DECL at repacking / de-serializing time.
>
> Richard.
>   
ollie is asking which global and static vars are referenced by each 
function, not the local variables.
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.

We have a pass that computes this info currently, the ipa_referenced 
vars, but i am considering blowing this pass away since the information 
is not currently being used in the compiler.   I need to chat with danny 
about this next time we talk.

However, the lto function body scanner/serializer can just as easily 
compute this when it  serializes a function.  We can then serialize this 
in a one section per compilation unit manner.  

kenny