profiling the native backend

[Stephen Weeks]

> > 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?

The first part of the profilier maps the instruction pointer counters back to C
line numbers.  The second part aggregates counters for C line numbers into human 
readable labels.  Without -b, the aggregation is by /* PROFILE ... */ comment in 
the C code.  With -b, the aggregation is done by C labels and switch cases,
which roughly correspond to CPS local functions.

> > 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:
.. 
> 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?  

None.
 
> Also, there might be some confusion at the basic block level.  For
> example, the initGlobals chunk is always emitted as:
...
> 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.

I think this shows why we need ProfileLevel1, which surrounds sequences of
assembly statements with a tag indicating the Machine IL block that they came
from.  That roughly corresponds to CPS local function level.