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

[Joe Hurd]

On Tue, 1 Apr 2003, Stephen Weeks wrote:

> OK.  So how's this for a definition:
>
> 	-graph <exp> evaluates <exp> to a set of nodes S as before.
> 	There is a dotted edge from A to B 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, and
> 	3. There is no path from A to B going only through nodes in S

Hmm. Having thought about this for a while, I think I was too hasty in
declaring solid edges to be more important than dotted edges. If
condition (3) above is eliminated, then I think the resulting graph
would be quite intuitive. Obviously there may be both a dotted and
solid edge between two nodes, but (as you say) this might even improve
readability.

> It is clearly subjective, but from the point of view of user
> understanding I believe that the default of not splitting is the right
> thing.

Agreed: I wasn't suggesting changing the default, just the program
that did the aggregating (from mlton to mlprof). The only
user-observable behaviour that I was proposing was "fewer dotted
lines", since I think this would produce a graph that corresponded
more closely with the user's own view of the program.

> I think it will be easier for users to make a positive list of the
> functions that should split (General.o, ...) than to make a list of
> the functions that should not be split.

Again, agreed. But in my proposed scheme, the user would simply
arrange for General.o to not satisfy the graph predicate, because all
nodes not in S would be automatically split to produce a "better"
indirect-call graph. I imagine -profile-split would then be used
rarely, to split multiple instances of functions that satisfy the
graph predicate.

> I do agree that it would be nice to move -profile-split from mlton to
> mlprof to avoid having to recompile.

Yes, I admit my suggestion was motivated by a slightly lengthy
experience of finding the functions to -profile-split :-)

> You seem to be suggessting an implementation technique for doing so
> -- namely, to split everything and then to combine with mlprof.
> Unfortunately, this doesn't quite work.

Oops, that rather throws a spanner in the works. Thanks for explaining
the problem.

> The only approach I can think of to move -profile-split would be to
> keep one bit of profiling data for each function and another bit for
> all of its instances.  Then, depending on whether the function is
> split, mlprof can do the right thing.  That increases the amount of
> profiling data and work done by the profiler, but not too much.  I'll
> look into it.

I'll keep my fingers crossed that this can work :-)

Regards,

Joe




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