cps & contification

[Stephen Weeks]

> Here's another one:
> 
> fun num_2(env_122, x_1816) = 
...
> 
> The reason I mention this one, is that my analysis computes that x_1824
> will return to num_2; this make sense, because L_677 and L_678 both return
> to L_675 which returns to ... num_2.  On the other hand, it seems that we
> could reasonably say that x_1824 returns to L_675.  Does this make a
> difference, or is it enough to combine top-level cps functions?  I think I
> know of a way of "shrinking" the return to narrow it down if that makes a
> difference.

It may make a difference, but I'm not sure if the contifier should worry about
it.  Putting the code deeper lexically may make other values available and avoid
repeated computations.  But there's lots of other passes where this is true.
There should probably be another pass in MLton that rearranges the local
functions to improve code.

> Here are the results from the benchmark suite.  First column is the number
> of functions in the program.  Successive columns show number of functions
> determined contifiable by combinations of the analysis.
...
> raytrace:
> functions: 303  110    0   13    6    0    0   42
> functions: 174   10    0    0    0    0    0   42
> functions:  38    0    0    0    0    0    0    5

Can you mail me the raytrace benchmark?  It hasn't made it into my benchmark
suite yet.

> The one other inconsistency that I discovered was in the regression suite
> with list.sml.  I got two functions determined to be call-contifiable, but
> neither cont- nor new- contifiable.  While this is true, what really
> happened was that the new analysis determined that those two functions had
> no return continuation (i.e., they were never called in execution of the
> program); interestingly, the cont-analysis did not determine that the
> functions had an empty continuation set.

This is weird, but I'm willing to ignore it since it seems we will be going with 
some variant of the new analysis pretty soon anyways.