[MLton-devel] common argument optimization

[Stephen Weeks]

> It's not that commonArg would hurt, it's just that flatten and
> localFlatten3 might expose some common arguments.  

Ahh.  Thanks.

> > > Here are the benchmark results.  I believe that the horrid compile
> > > time for hamlet is due to the dominator computation on the graph G.
> >
> > Wow.  I'm pretty surprised even with the big graph.  After all,
> > dominators is basically linear.  Maybe the -diag hurt.
> 
> Maybe, but I'm pretty sure it was the size of the graph.  Remember, the
> naive version was creating a graph with a node for each variable in the
> SSA function; that's much bigger than the dominator graph of the basis
> blocks.  Also, I wasn't thinning repeated edges.  Anyways, the pass still
> takes close to 5 seconds on a self-compile, which is relatively high
> compared to many of the other passes.

OK.  If you think it's due to dominators, the implementation still has
quite a bit of room for constant-factor speedups.  One simple one that
comes to mind would be to use an array for each of piece of node info
(ancestor, bucket, child, ...) instead of per-node tuple of refs.
That would at least save a lot of space (until and if we ever
implement ref-flattening).


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