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


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.


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