[MLton-devel] Fwd: C back end for MLton

[Matthew Fluet]

> > As to gcc optimization -- sure, it may have improved.  But, there are
> > some fundamental limitations to compiling to C and using gcc that will
> > always make it harder to do as well as a well-written native backend.
> > On example is the much better aliasing information that our native
> > backend has.
> 
> If the conclusions will always be "C back ends are worse than native back
> ends" and/or "gcc is buggy", then tell me now and we can stop wasting
> time discussing it.  My guess is that MLton doesn't have deterministic finite
> automata models of x86 processor execution in its native back end,
> or any number of other optimizations, that gcc has.

You are, of course, quite correct that MLton doesn't have any
sophisticated x86 model or optimization methodology.  And, knowing exactly
how the native codegen is implemented, I squirm a little uneasily when its
virtues are extolled. 

I would never claim that MLton's instruction selection, sheduling,
register allocator, etc. are better than gcc's.  The win comes from the
interface -- obviously the interface between MLton's lowest level IL and
MLton's native codegen dove-tail quite nicely, whereas the interface
between the lowest level IL and gcc's native codegen (namely, the C
programming language) isn't as seamless a match.  In particular, a lot of
useful information that is explicitly or implicitly available at that low
IL is lost in the translation to C and cannot be recovered by gcc.  And,
this is a recognized problem: witness the VPO, MLRISC, C-- (and, to some
extent, gcc) projects. 

If there is low-hanging fruit in the C-codegen, by all means take it.  As
your initial analysis points out, there is little low-hanging fruit left
in this incarnation of the native codegen.  Any substantial improvement
would almost certainly require rewriting the codgen almost from scratch --
at which point we return to the questions of time, resources, and support. 
Alternatives are to target one of the "portable" backend projects
mentioned above (that focus on low-level optimization), ensuring that the
information available at translation time that we believe contribute to
the native codegen's performance gain can be passed on. 



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel