[MLton] Question on profile.fun

[Matthew Fluet]

> > > If you are using the move of a constant value into a gc variable, why do you
> > > still need to keep the profiling mark data? It seems to me this is an unfair
> > > comparison. Right now, those extra labels prevent some optimization, right?
> > 
> > Correct.  There is another experiment to be done where labels are not 
> > inserted into the Machine IL code.
> 
> I am quite puzzled by why the presence of a label inhibits optimizations.
> What kind of things does it prevent MLton from doing? Common subexpression
> elimination, or what? Or can you not replicate labels (thus meaning less
> inlining...)? Just curious.

We are well past the point where we are doing any inlining.  The only
optimizations done by the native codegen are little peephole
optimizations.  Furthermore, all of the codegen optimizations work at the
level of basic blocks.  Evolution has led to a representation of the x86
IL whereby a basic block is represented by a label, an optional profile
label, a sequence of non transfer instructions, and a transfer
instruction.  The fact of the matter is that profile labels cannot appear
embedded in the sequence of instructions.  So, inserting profiling labels
effectively means that the instruction stream is interrupted at every
profile label.  Smaller basic blocks means that there is less opportunity
for optimization.

But, depending on your view, maybe this is what you want.  The fact that
profile labels prevents basic blocks from one source function from
"mixing" with the basic blocks from another source function means that
optimizations can't move computation from one block to another (and,
hence, from being charged to the wrong source function).  I don't know how
this fits into Stephen's "principle of not interfering with what you're
measuring".