#2224: -fhpc inteferes/prevents rewrite rules from firing
---------------------------+------------------------------------------------
Reporter: dons | Owner: [EMAIL PROTECTED]
Type: bug | Status: new
Priority: normal | Milestone:
Component: Code Coverage | Version: 6.8.2
Severity: normal | Resolution:
Keywords: rules, hpc | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
---------------------------+------------------------------------------------
Comment (by simonmar):
Replying to [comment:2 simonpj]:
> In general, coverage testing is incompatible with optimisation, although
it seems surprising (to me) robust:
> {{{
> f x = g (h x)
> g x = x
> h x = x
> }}}
> then if we inline busily we'll get
> {{{
> f x = x
> }}}
> and in fact this ''does'' happen, but none of the relevant ticks are
lost. In effect, the optimiser knows how to commute stuff with ticks,
because ticks get encoded as `case` expressions. There's a paper in
here, actually, because the code does get shaken around quite a bit,
despite the ticks littering it. (Mind you, we don't yet have an
operational semantics to tell us what ticks ''should'' do, though that
would not be hard to write. That too should be in the paper.)
We said a little about this in the GHCi debugger paper, although I agree a
formal treatment would be useful. You may remember the basic idea is that
we tell the simplifier that the tick has side effects. The principle we
want the simplifier to preserve is that the tick in `case tick of _ -> e`
should be evaluated ''if and only if e would be evaluated by the standard
lazy operational semantics''. We don't care about ordering: the
simplifier can re-order two ticks, as long as it can be sure that both
expressions would have been evaluated according to the semantics. (in the
debugger you'll see the effect of reordering, but HPC doesn't care).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2224#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
