[MLton-user] experimental release 20051109

[Matthew Fluet]

> Like John, these errors go away with -00 option.  They also go away with 
> -fno-inline option, which was my guess as to how gcc was duplicating 
> code.

A little more investigation reveals that -fno-tree-ch suffices to quell 
the errors.  The gcc documentation describes the tree-ch optimization as 
follows:

   Perform loop header copying on trees. This is beneficial since it
   increases effectiveness of code motion optimizations. It also saves one
   jump. This flag is enabled by default at -O and higher. It is not
   enabled for -Os, since it usually increases code size.

This agrees with the observed behavior: a loops in SML are almost 
invariably defined by recursive functions, hence would receive a 
distinguished profiling label.  MLton successfully translates the 
recursive function into a local loop, with the profiling label in the loop 
(including the header).  Duplicating the header duplicates the profile 
label.


BTW, for those interested in how this was tracked down, I compiled with 
-cc-opt -fdump-tree-all, which is similar to mlton's  -keep-pass ".*" 
option: it emits an intermediate form of the code for each optimization 
pass.  I did grep  -c MLtonProfile747 z.1.t*  and looked for the pass at 
which the count went from 1 to 2.  This clearly pegged  ch  as the 
culprit.