[MLton-devel] New release of MLton: call-graphs

[Stephen Weeks]

> Yes, but with one small difference. I was imagining that the -graph
> predicate would be evaluated for each function (rather than each split
> of a function) by looking at the aggregate counts (and for the
> reachability properties, declaring that a function satisfies the
> property if at least one split of the function does).
> 
> But given that you saw things differently, how about this compromise
> to compute the set of graph nodes:  using aggregate counts by default
> for all functions, except those specified by the -profile-split
> regular expression.

This makes sense to me.  Here's my latest attempt to define an
algorithm.

1. Split everything in mlton and keep the precise call graph.
2. While the program runs, keep counts for both the split and unsplit
    versions of each function.
3. In mlprof,
   a. Compute the set of nodes, S, from -graph on the precise call
      graph as follows: 
      (thresh x) = { f | f is -profile-split and the ticks for this split
			 version of f >= x }
                   U { f | f is not -profile-split and the ticks for the
			   unsplit version of f >= x }
      thresh-gc and thresh-stack are similar
      The remaining operators (pred, succ, and, or, ...) are computed on
      the precise call graph.
   b. In the precise call graph, for every function f that is not
      -profile-split and has some occurrence in S, merge all
      occurrences of f together, removing all the occurrences from S
      and adding the merged node to S
   c. Add a dotted edge from A to B, both in S, iff
 	1. A and B are in S, and
 	2. There is a path from A to B of length >1 going only through
 		nodes not in S
   d. Eliminate the nodes not in S.

OK, this looks pretty complicated.  Why do I think it makes sense?

If nothing is -profile-split, then I claim that the algorithm
generates a graph with identical nodes and solid edges, and a possibly
proper subset of the dotted edges, to an approach that works solely on
the unsplit call-graph.  I.E., if nothing is -profile-split, what my
approach is buying us is more precise dotted edges, and nothing else.
And I think that's what we're looking for.

Also, if -profile-split is used, then the user will use thresh and
friends on the split versions and will see the split versions that
appear due to -graph, both of which make sense to me.

And, there is no longer a problem with combining some of the splits of
f.  If f is -profile-split, we combine none, and if f is not
-profile-split and will be displayed, we combine all.

> But perhaps you think this isn't a good overloading of the
> -profile-split argument? After all, it won't be possible to profile
> each split of a function f separately, but display f as a combined
> node in the resulting graph. [Confusion: would this represent a
> combination of (i) the splits of f that satisfied the graph predicate,
> or (ii) all splits of f?]

Given my algorithm above, we will profile splits of f separately and
combined.  Then if we decide to display f combined (because it is in
-graph and is not -profile-split), it will be (ii), a combination of
all the splits of f.  After all, since the user didn't profile-split
f, he doesn't even know that the splits exist, so it doesn't make
sense to me to keep some splits and not others.


Comments on the new approach appreciated. 

One other thing I'd like to point out is that I'm beginning to wonder
about the necessity of -profile-split.  It was originally added to
solve the problem where a utility function needed to be split so that
when it was ignored by mlprof, spurious edges wouldn't be added.  With
the new approach, this is no longer a problem since the split version
of a function that is not -graph'ed will always be used.  So, the only
remaining use of -profile-split is when the user wants to actually see
a split function.  I suppose that could happen when you want to
profile a library function, though.







-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel