profiling the native backend

[Matthew Fluet]

> You also need something similar for the -b option, which does stuff at the level 
> of local functions in CPS.  -b is useful when CPS function granularity is too
> large.  

What does the -b option do exactly?

> Actually, it's probably useful to have three levels of granularity
> 	CPS toplevel function
> 	CPS local function
> 	assembler basic block

Sounds reasonable.  I think the same strategy will work at the outer two
levels:

ProfileLevel0_CPSName_begin:

ProfileLevel2_BasicBlockName_begin:
BasicBlockName:
<instructions>
ProfileLevel2_BasicBlockName_end:


ProfileLevel0_CPSName_end:


I'm not sure about the middle level.  In particular, what gaurantee is
there that the blocks corresponding to a local function will end up being
contiguous?  

Also, there might be some confusion at the basic block level.  For
example, the initGlobals chunk is always emitted as:

.p2align 2
.global initGlobals_0
initGlobals_0:
statementLimitCheckLoop_0:
        movl (gcState+8),%eax  # load gcState.limit
        cmpl %eax,%esi         # compare with gcState.frontier
        jbe skipGC_0
        <normal doGG instructions>
        jmp *%edx              # jump to gcState.stackTop
.p2align 2
skipGC_0:
        <normal instructions associated with initGlobals>
        jmp main_0
.p2align 2
.global L_97
.long 0
L_97:                          # loop through limit check again
	subl $4,%edi
        jmp statementLimitCheckLoop_0

So, at the basic block level, time in what we normally consider
initGlobals is counted under skipGC_0; something similar always occurs
with limitChecks.  Maybe these sort of issues would be solved by the CPS
local function level.