Andy Gill wrote:

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

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.

instead of

  Note (Tick "M" 23) e

how about

  case tick# "M"# 23# of DEFAULT -> e

where tick# is a PrimOp, and the case expression is compiled to inline code (ie. no extra info table / return address for e). The PrimOp would be marked as having side effects, so the simplifier wouldn't rearrange code around it. There would be nothing HPC-specific in CoreSyn, CorePrep, CoreToStg, or StgSyn. All you need to do is provide an implementation for tick# in CgPrimOp. I'm probably missing something!

The "M"# is a Literal - a MachStr. I imagine you don't need the package name, because it is always the current package name (the code generator for tick# can prepend the package name if it needs to). A bit of cleverness in CgPrimOp is required to common up all the module names, I guess.

What happens with cross-module inlining?

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!

Wow, that's amazing.  We need to get writing some more tests!

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

Reply via email to