patch applied (ghc): TickBox representation change

[Andy Gill]

Thanks SimonM for answering my question!
To give more details:

* ticks should be done on *entry* to a expression, not exit.

so what is the strictness of

  tick<n> e

?

If you mark tick as strict in e, then e might be explicitly pre- 
evaluated (and perhaps throw an exception, before being ticked).
If you mark tick as lazy in e, then we build many, many thunks, and  
disable almost every optimization. (slowdown of ~30).

But

	case tick<n> of
	   DEFAULT -> e

does exactly the Right Thing!

* I've seen the double tick-merge happen. Its not a big deal, as it  
reflect sharing anyway. I compared
the output of a large program, before and after the change, and this  
merging and one other trivial
difference was the only change in tix info. All within the scope of  
our Haskell semantics under
optimizations.

* We need have binary tick boxes so that we can have accurate branch  
counts, because I want to use this
information for optimization purposes later.  Can imagine the inliner  
using Hpc information to drive inlining :-)
The problem that

   tick<n> True

Is CAF-able. So

  case expr of
    True -> tick<n> True
    False -> tick<n> False

Only gives 1 or 0 answers.

* I've started a wikipage, as requested.

	http://hackage.haskell.org/trac/ghc/wiki/Commentary/Hpc

It is not under .../compiler,  because it is crosscutting, and  
includes RTS changes.

Feel free to add questions; just mark them QTA: (question to Author/ 
Authority).

("QTA:" might be a good annotation for the wiki. If you fill  
something, and are not 100% sure,
you can QTA: a question, and we can search for unanswered QTAs. The  
Author/Authority would
change the page, answering the question or putting in a link.)

Andy

On Dec 4, 2006, at 1:52 AM, Simon Marlow wrote:

> Simon Peyton-Jones wrote:
>
>> I had a look at what you did.   Generally looks good.  Much better  
>> than the Note version, as I hope you agree!   (You seem to have  
>> deleted quite a bit of code!)
>> Here's a qn.  I thought you were going to do ticks like this:
>>         dsExpr (HsTick a e) = tick{a} e
>> but instead you have
>>         dsExpr (HsTick a e) = case tick{a} of DEFAULT -> e
>> I think that both are probably fine, but the implications are not  
>> clear to me.
>
> It's perhaps because I suggested we use the case form.  If we had
>
>   tick{a} e
>
> then we really don't want e compiled to a thunk.  So somehow this  
> must turn into the case form in the back end:
>
>  case tick{a} of DEFAULT -> e
>
> but just declaring tick{a} to be strict won't do this: it'll give you
>
>  case e of DEFAULT -> tick{a} e
>
> Perhaps this still works, I don't know.  To me it seems like a  
> longer way around; the case form more directly says what you want  
> to happen.  But maybe I'm missing something?
>
>   The former seems more robust somehow.  For example if we have
>>         case tick{a} of DEFAULT -> ....(case tick{a} of DEFAULT - 
>> > ...)
>> GHC might eliminate the inner tick.  Would that be OK (after all,  
>> you're only checking coverage, and it's covered)?
>
> One of the suggestions was to use a PrimOp (like the foreign call  
> op) for tick, which would prevent the simplifier from eliminating  
> the inner tick because the PrimOp would be declared as having side  
> effects.
>
> Cheers,
> 	Simon