patch applied (ghc): Haskell Program Coverage

[Andy Gill]

On Oct 26, 2006, at 1:18 AM, Simon Marlow wrote:

> Andy Gill wrote:
>> On Oct 25, 2006, at 2:01 AM, Simon Marlow wrote:
>>
>>> The use of Notes in Core is a slight concern - the simplifier  
>>> will  almost certainly rearrange code without paying attention to  
>>> the  Notes, indeed it looks like you have some hacks already to  
>>> avoid  this (the extra cases in exprArity look quite strange).   
>>> Weren't  you using explicit expressions before?  Why the change  
>>> of design?
>>  Compile time and less hacks. We use Note for SCC right now, so  
>> this  seemed like the right place to put it. The exprArity
>> hack is there because of the code
>>     \ x -> _tick \ y -> expr     really does have aritty 1; it  
>> will  translate into
>>     \x -> case tickme 0 of
>>               _-> \ y -> expr
>
> We should choose the design that is as modular as possible; that  
> is, requires the fewest changes elsewhere.  The example above  
> indicates to me that using a Note is perhaps not the best design,  
> because most of the simplifier assumes that the semantics of 'Note  
> e' are the same as 'e', but this breaks that assumption.  Indeed,  
> you already needed to modify various predicates in the simplifier  
> to do something special for Tick expressions.

Sure.  I'm open to other designs. One reason I used Note was it  
worked with unboxed typed, unlike a polymorphic function.

> Essentially you've added an extra constructor to Expr but hidden it  
> inside Note.  I suspect we'll be finding parts of the simplifier  
> and other core-to-core passes that need to be modified for a long  
> time.
>
> I realise that SCC already breaks the rules a bit, and that's  
> unfortunate too. But it doesn't seem as invasive as the Tick  
> annotations.

The main reason was the need for static fields, that contain the  
module name and tick number. I'm happy to defer back to PrimOp,
but perhaps we need a Constructor that both SCC and Tick can use? I  
would also consider with a PrimOp with
static arguments.  Perhaps we need a new type of Id instead, sortof  
like a PrimOp Id.

>> The new design has less backend hacks in CorePrep and CoreToStg.
>
> Ok, can you explain why that is?

1. Because I hate code of the form:

exprTrans (App (Var id) e)  | DataMagicId <- maybe_getPrimId id = ...

2. Because I want the tick counter to be *static*, and share the  
module reference.

> Please don't take this as a criticism - HPC is a fantastic addition  
> to GHC.  I'd just like to explore the design and see if there are  
> any ways we could improve it, and hopefully give ourselves fewer  
> headaches in the future.

Thank you. No criticism taken; I just want the best Hpc: accurate,  
fast, and easy to maintain.

The result of bootstrapping GHC, then running all the tests is  
online, BTW:

	http://www.galois.com/~andy/ghc/hpc_index.html

GHC seems to do really well, most of the code is actually tested! We  
done!

I do not completely trust the output (yet) but the fact a ghc  
bootstrapped
with -fhpc enabled runs most of the GHC tests successful is great news.
I'm tracking down the few that were different between the original  
stage2
and the -fhpc stage2.

AndyG