On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> 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.
