Re: [lto] function to DECL associations for WPA repackaging

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

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.
>