[lto] function to DECL associations for WPA repackaging

[Kenneth Zadeck]

Daniel Berlin wrote:
> On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck
> <zadeck@naturalbridge.com> wrote:
>   
>> 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.
>>     
>
> Referenced_vars already includes all of these, efficiently indexed for
> you by UID.
> Not that it is necessarily the right answer, but it includes more than
> the local variables.
>   
but we do not serialize this, and we should not.  we know what global 
vars each function references when we serialize it, it is not a big deal 
to keep track of that as we do so and write it into a separate section 
that the function body.

kenny