Changes between Version 4 and Version 5 of Commentary/Hpc


Ignore:
Timestamp:
Dec 19, 2006 7:39:23 AM (7 years ago)
Author:
AndyGill
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Hpc

    v4 v5  
    77   `HsTick` 
    88 * Each `HsTick` has a module local index number. 
    9  * There is a table (The Mix datastructure) that maps this index number to original source location. 
     9 * There is a table (The Mix data structure) that maps this index number to original source location. 
    1010 * Each `HsTick` is mapped in the Desugar pass with:  
    1111{{{ 
     
    2020 * The !CoreToStg Pass translates the ticks into `StgTick` 
    2121{{{ 
    22   .. (case tick<m,n> of DEFAULT -> e) = .. StgTick m n (... e) 
     22  coreToStgExpr (case tick<m,n> of DEFAULT -> e) = StgTick m n (coreToStgExpr e) 
    2323}}} 
    24  * The `Cmm` code generate translates `StgTick` to a 64 bit increment. 
     24 * The `Cmm` code generator translates `StgTick` to a 64 bit increment. 
    2525 
    26 TO BE CONTINUED. 
     26Other details 
     27 * A executable startup time, we perform a depth first traversal some module 
     28   specific code, gathering a list of all Hpc registered modules, and the 
     29   module specific tick table.  
     30 * There is one table per module, so we can link the increment statically, 
     31   without needing to know the global tick number. 
     32 * The module Hpc.c in the RTS handles all the reading of these table. 
     33 * At startup, if a .tix file is found, Hpc.c checks that this is the same 
     34   binary as generated the .tix file, and if so, pre-loads all the tick counts 
     35   in the module specific locations. 
     36 * (I am looking for a good way of checking the binaries for sameness) 
     37 * At shutdown, we write back out the .tix files, from the module-local tables. 
    2738 
    2839=== Binary Tick Boxes === 
    2940 
    30 The reason we do not translate tick boxes using. 
     41There is also the concept of a binary tick box. This is a syntactical boolean, like a guard or conditional for an if. 
     42We use tick boxes to record the result of the boolean, to check for coverage over True and False. 
     43 
     44 * Each `HsBinaryTick` is mapped in the Desugar pass with:  
    3145{{{ 
    32  if e then (tick a True) else (tick b False) 
     46  dsExpr (HsBinaryTick t f e) = case e of  
     47                                 { True -> case tick<modname,t> of DEFAULT -> True 
     48                                 ; False -> case tick<modname,f> of DEFAULT -> False } 
     49 
    3350}}} 
    34 is that `tick<a> True` is a CAF, and gets lifted to top level. This maintain the coverage information, but does not allow for entry counting. If the if/then/else is called 100 times, and no exceptions were thrown, then you would expect the binary tick count to add up to 100. We hope to use Hpc to do path optimization in the future, so real numbers are important. 
    35   
    36 Also, we translate the tick late to allow case-of-case to work, allowing unboxed compares to work without generating boolean intermediates. We still need to push one optimization into the simplifier for this to work well. 
     51* After desugaring, there is no longer any special code for binary tick box. 
     52 
     53== Tracer Mode == 
     54 
     55There is a mode '-fhpc-tracer', which compiles code which outputs .rix files; a record 
     56of everywhere the program goes. 
     57 
     58 * by default, the -fhpc-tracer program does exactly the same as a -fhpc compiled program. 
     59 * setting the env var HPCRIX causes an additional action, at each tick (and a few other important events), 
     60   the global tick number is written into the file named in HPCRIX. 
     61 * Typically, HPCRIX would point to a named pipe. 
     62 
     63There is a Hpc tracer which sets up both the named pipe, and the HPCRIX variable exactly for dynamically 
     64interacting with the tracer output.