On Oct 27, 2006, at 1:50 AM, Simon Marlow wrote:
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.
I tried this, and the tick# M# 23# got lifted out into a CAF, and was
evaluated only once :-) Perhaps the PrimOp's side_effect flag
was off on that build, though. Does the side_effect flag stop this?
foo x = case tick# "M"# 23# of
DEFAULT -> x
does not equal (in HPC world)
lvl = tick# M# 23#
foo x case lvl of
DEFAULT -> x
Perhaps we could a return type for tick# that reflects the non-
sharing/non-lifting part? Would a Int# return enforce this?
I'll play around with this in a bit.
WRT CorePrep and CoreToStg
- The CorePrep stage translates BinaryTickBoxes into TickBoxes.
There are optimization reasons why this is done.
- I believe the Stg parts of Hpc could be removed if we use a prim.
What happens with cross-module inlining?
It works just fine. The Note is transmitted between modules with no
problem, and the backend generates code that links
with the coverage tick table in the correct module.
AndyG
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
