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

_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to