[MLton] cvs commit: world no longer contains a preprocessed basis library
Wed, 10 Dec 2003 11:47:37 -0800
> My feeling is to agree with Matthew that file level granularity is a bit too
> coarse for code that I think of as library code. If I have some structure
> with a bunch of functions to deal with some type and the program only uses
> some of the functions, I wouldn't want all the code to be in the executable.
> I guess real dead code will remove the case where the functions are values,
> but I assume that it would fail in other cases because of worrying about the
> possibility of exceptions being raised.
Right -- we have very agressive (and semantics-preserving) dead-code
elimination that runs on the SSA. That will certainly eliminate
unused functions. The only place where we may have problems is when
there are side effects: exceptions, nontermination, mutation. One
argument why the basis library may be a special case is that it does
stuff with primitives (on e.g. threads and signals) that we want to be
very careful about making it into the whole program because the
presence of these primitives greatly affects the optimizer. But, I
guess that same argument transfers to user libraries that might use
any of those special basis libraries.
One thing to try would be to see how much work it would take to make
the basis library work with file granularity. If we could do that, I
would be much more confident about using it everywher.
Another thing to try would be to run all the benchmarks and a self
compile with and without dead-code to see how much turning it off
Overall, I find the per-declaration non-semantics-preserving dead-code
elimination too hard to program with. I remember getting bitten
several times when writing basis library code.
The best solution of all would be to turn off the
non-semantics-preserving dead-code elimination completely. I would
think a lot of user library initialization could be written using
promises -- that's what I do in the URI library for compiling regexps
to DFA's. I think the SSA dead-code elimination will do the right
thing for promises. And promises seem better since the delaying is
expressed in the source.