[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