On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: >> >> On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck >> <[EMAIL PROTECTED]> wrote: >> >>> >>> Richard Guenther wrote: >>> >>>> >>>> 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. >>>> >>>> >>> >>> 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. Richard.
