[MLton] Question on profile.fun

[Matthew Fluet]

> I'm still wondering why you need -profile-exclude and -profile-lib.
> Why not go for two flags with opposite meanings, like
> 
> 	-profile-include <regexp>
> 	-profile-exclude <regexp>
> 
> and refer to the special shortened names in the regexp.  So, for
> example, the default would be "-profile-exclude '<basis>'".

Here's what I've worked out thus far:

      fun wantedSource (si: SourceInfo.t): bool =
	 if SourceInfo.isC si
	    then false
	    else (case SourceInfo.file si of
		     NONE => true
		   | SOME file =>
			List.foldr
			(!Control.profileInclExcl, true, 
			 fn ((re, keep), b) =>
			 if Regexp.Compiled.matchesAll (re, file)
			    then keep
			    else b))
      fun keepSource (si: SourceInfo.t): bool =
	 profile <> ProfileCount
	 orelse wantedSource si

    fun enter (ps: Push.t list, si: SourceInfo.t): Push.t list * bool =
	...
	      | SOME (node' as InfoNode.T {info = si', ...}) =>
		   (* 
		    * si  : callee
		    * si' : caller
		    *)
		   if keepSource si 
		      andalso
		      let
			 open SourceInfo
		      in
			 equals (si', unknown)
			 orelse
			 (not 
			  (equals (si, gcArrayAllocate)
			   orelse not (wantedSource si)
			   orelse (isC si
				   andalso (not (wantedSource si')
					    orelse equals (si', main)))))
		      end 

This seems to approximate the current behavior of profiling.  I haven't 
given much thought to -profile-c <regexp> style flags yet.  Also, I've 
noted that even with the current implementation, sometime basis code is 
marked in time profiling.  For example, if you rig doc/profiling/tak.sml 
to work on IntInf.int, then I see the following:

mlton -profile time -profile-basis false tak.sml
./tak
mlprof tak mlmon.out
15.79 seconds of CPU time (0.00 seconds GC)
   function      cur 
--------------- -----
Tak.tak1.tak2   58.2%
IntInf.bigMinus 23.0%
Tak.tak1        18.8%



Finally, and much to the chagrin of those wanting to map source code onto 
assembly code, I wonder if we can't simplify time profiling by associating 
a  currentSourceSeq  field in the gc state and having  profile.fun  
explicitly change the field as appropriate when time profiling.  This 
would appear to simplify the time profiling, as we wouldn't need to 
inspect the PC state, figure out how to grab begin and end of text 
segment, etc.  That ought to make it easier for new platforms to support 
time profiling.