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.
my sense is not to associate put this directly in the cgraph but to keep
it as a side table that is indexed by something like the cgraph node
id. The reason for leaning in this direction is that "what happens in
the cgraph stays in the cgraph", and the infomation we are talking about
here is is only really useful for the whopr repackaging. This is why i
have resisted honza's wanting to associate other ipa local information
in the cgraph.
We have a pass that computes this info currently, the ipa_referenced
vars, but i am considering blowing this pass away since the information
is not currently being used in the compiler. I need to chat with danny
about this next time we talk.
However, the lto function body scanner/serializer can just as easily
compute this when it serializes a function. We can then serialize this
in a one section per compilation unit manner.
kenny
