#12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2392 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata):
So we return an un-decorated binding orig_pairs
It is not necessarily un-decorated, but may have information from a previous pass of the Demand Analyzer. I was under the impression that we generally want to make sure that running the demand analyzer updates _all_ strictness signatures and demand information, and does not leave any around from a previous iteration. I am never fully confident that I can overlook all the assumptions in the code and the consequences, that’s why I am much more confident with simple invariants such as “all code has been processed and annotated by the demand analyzer at least once.”
We should just return the un-extended environment! (If a variable isn't in the environment it's treated as having topSig.) Simple.
Is that safe? `topSig` (actually `nopSig`, since there is no top strictness signature) has an empty environment, so if the RHS of the definition makes use of a free variable, `nopSig` effectively has an absent demand on that. I guess this is the reason for the `lazy_fv` fuss. I think in some other discussion you wondered whether that is really required. By having the analysis set to `topSig` it definitely has to.
Conclusion: if the fixpoint limit is reached:
* return an environment that simply does not mention the new binders
Agreed, if `lazy_fv` works as advertised.
* set all the binders to no-strictness-at-all
What about demand and strictness signatures attached to binders somewhere nested in the RHS of one of the equation. Should we zap them as well?
Finally, the loop function in dmdFix would be much better if it took a SigEnv rather than an AnalEnv, wouldn't it?
Or maybe even just a list of `StrSig`s, to make it clear that only the strictness signatures of the recursive binders vary. All in all I wonder if avoiding an extra iteration (after we already did 10) in the corner case is worth the extra complication of having to think about how to properly abort the analysis from in an invalid state. Simply jumping to a definitely sound state, and being able to guarantee that a pass of the demand analyzer processes all code appears to be simpler and more reliable to me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12368#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler