[MLton] getText{Start,End} considered harmful

Matthew Fluet fluet at tti-c.org
Tue Sep 30 12:15:39 PDT 2008


On Sun, 28 Sep 2008, Wesley W. Terpstra wrote:
> On Sun, Sep 28, 2008 at 7:01 PM, Matthew Fluet <fluet at tti-c.org> wrote:
>> There are/were other issues with the approach to time profiling:
>>  http://mlton.org/pipermail/mlton/2005-November/028283.html
>>  http://mlton.org/pipermail/mlton-commit/2005-November/000238.html
>
> Those emails propose to use code-modification for the C codegen and
> the labels for the native codegen. I didn't intend to change this.
> AFAIK, the C-codegen profiling path is completely unaffected.

Agreed that the C-codegen profiling path is unaffected by your changes. 
But, I brought up that old thread because it lays out the arguments for 
(and against) keeping the time overhead of profiling low.  Something not 
brought up in that thread is that, while using code labels in the native 
codegens works, it does complicate the native codegens somewhat, because 
everytime a new assembly basic block is introduced, it needs to conjure up 
the right profiling information to associate with the new profiling label. 
Also, it is unlikely that we could easily use labels in a reusable codegen 
framework (e.g., MLRISC, C--, LLVM).

Just as you noted that the sourceLabels could be compressed by eliminating 
duplicates, the 'field' approach to time profiling in the C-codegen (and 
available on the native codegens) could probably be improved by avoiding 
idempotent assignments to the curSourceSeqsIndex.

Anyways, your approach is certainly expedient for the problem at hand. 
And the self-compile didn't suffer from the binary search.  So, consider 
the above just general comments.



More information about the MLton mailing list