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
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
