[lto] function to DECL associations for WPA repackaging

[Kenneth Zadeck]

Richard Guenther wrote:
> On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck
> <zadeck@naturalbridge.com> wrote:
>   
>> 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.
>>     
>
> Well, I still do not see the difference of simply serializing referenced_vars.
> Note that referenced_vars also includes _reachable_ globals (through
> static initializers).
>
> ipa-reference is useful to find statics that are never written to (it promotes
> them to const).  Of course a proper ipa-mod-ref and proper ipa-call-clobbering
> would be even more useful.
>
>   
i had forgotten that it did this.
> Richard.
>