[MLton] profiling question

[Stephen Weeks]

> I get into trouble generating the mlmon.out file. Right now profileflatten
> should work exactly like alloc, but increment by one instead of bytes
> allocated. But when I run it on a test file I get no mlmon.out file. I am
> using tak.sml from the profiling examples in the doc section.  It seems
> like profile.sml in the basis library generates the mlmon file. 

Right, but even if it fails for some reason (like out of memory), the
profileEnd function in gc.c that will spit out the mlmon file.  So, if
you're not seeing one, it's because you're not telling the codegen to
emit profiling information.  You can compile with -keep g and look at
the generated C file to see what it defines for "sourceSeq",
"sourceSeqs", "sourceLabels", "sources", etc.  If those are all empty,
then there is no profiling info.

> It does not look like it checks what type of profiling is being done
> to generate the file.

Right.  The same kind of file is generated for allocation or time
profiling.  That should be true for flatten profiling as well.

> I have been looking through the other files that have to do with
> profiling, but I am not sure if any of these need modification. Are
> there any files I should be looking at besides profile.fun in the
> backend?

Looking at profile.fun, I see that Profile.profile doesn't do anything
if !Control.profile = Control.ProfileNone.  I'm not sure what you did
for your command-line switch, but I think the right thing to do is to
modify the "-profile" switch to take a new specifier, say "flatten",
and to set profile to ProfileFlatten in that case.

To look into other problems, you can compile -keep ssa to see if there
are any Profile Enter/Leave statements in the SSA.  If not, there is
clearly a problem.  One possible problem is that they got simplified
away by the SSA simplifier, which assumes it is safe to eliminate a
Profile Enter immediately followed by a Profile Leave.

Also, if you've just modified profile.fun to change the increment from
bytesAllocated to one, then that's not enough.  You need to make sure
that for every Profile Enter/Leave pair, you insert a call to the
increment.  The behavior is different enough from the current
allocation and time profiling that you will surely need some special
case code turned on for ProfileFlatten.

Perhaps one way to work around all these problems is to insert a
Runtime call in the SSA to do the increment, in between the
ProfileEnter and ProfileLeave.  Then, profile.fun doesn't have to do
much except leave those calls in place, and create all the tables that
it already knows how to create.