[MLton] fixing -codegen c -profile time for the release

[Matthew Fluet]

> Our basic approach to profiling is to propagate annotations
> from the front end to the codegen, and ask the codegen to insert
> labels into the executable, so that the runtime can map IP to label
> and back to annoation.  This works flawlessly with the native codegen,
> because our native codegen never duplicates the labels.

This isn't quite true.  The native codegen is able to use the 
Machine.ProfileInfo.modify function to clone profile labels.  The native 
codegen wants the freedom to duplicate labels (I believe that the reason 
we do so is not for actual optimization, but for primitives that must be 
implemented by multiple basic blocks) and to drop labels (this is for 
optimization reasons, though the  weak  attribute on the C side appears to 
handle this situation well).

> This fails with gcc 4, which sometimes duplicates labels.  Furthermore, 
> it could have failed with gcc 2 or 3, at least according to the spec, 
> but hasn't because we've been lucky.

Agreed.  Also, it isn't entirely clear that even in the absence of 
duplication, gcc won't munch the program in such a way that our volatile 
assembly labels really cover the right portions of code.

> I don't entirely understand Florian's separate-section
> solution, but I still see the volatile asm, so I guess it would have
> similar problems.

I think what Florian was attempting to do was to use local (anonymous) 
labels, which could be freely duplicated, because the assembler would 
assign each one a unique name.  The trick then is figuring out how to 
populate the sourceNames array with label/sourceSeqIndex pairs.  Florian's 
idea was to construct this array in a separate section, where it 
presumably would be the only thing, so somewhat easier to pull back into 
the C world.

However, looking at the assembler docs, I don't believe that local 
(anonymous) labels can span multiple sections.

> So, my conclusion is that we should go with Matthew's approach for the
> release.  But it should only be used when time profiling with the C
> codegen -- there's no reason to hurt profiling in other situations.
> The simplicity, robustness, and portability of the approach outweigh
> the performance impact in this one case.

I knew there was a reason I didn't blow away the directory where I was 
doing those experiments. ;-)