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
