This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [lto] function to DECL associations for WPA repackaging
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.