patch applied (ghc): Haskell Program Coverage
andy at galois.com
Fri Oct 27 18:12:14 EDT 2006
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
>> 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
>> 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.
More information about the Cvs-ghc