<div dir="ltr">I implemented -flate-dmd-anal last year<div><br></div><div>Here's some outdated notes about my initial implementation. I share it in order to indicate what thoughts were in my mind at the time (eg re motivation).</div><div><br></div><div><a href="https://ghc.haskell.org/trac/ghc/wiki/Frisby2013Q1#LateStrictnessWW">https://ghc.haskell.org/trac/ghc/wiki/Frisby2013Q1#LateStrictnessWW</a><br></div><div><br></div><div>Aha! More up-to-date info here, including links to some of the older, motivating tickets.</div><div><br></div><div><a href="https://ghc.haskell.org/trac/ghc/ticket/7782">https://ghc.haskell.org/trac/ghc/ticket/7782</a><br></div><div><a href="https://ghc.haskell.org/trac/ghc/wiki/LateDmd">https://ghc.haskell.org/trac/ghc/wiki/LateDmd</a><br></div><div><br></div><div>Also, I now suspect this pass is risky: I think it may enter unused arguments. I realize I didn't understand that stuff well enough at the time. This definitely deserves some attention if people are using the flag.</div><div><br></div><div>To answer your question directly: I do not recall explicitly considering single-entry thunks when implementing -flate-dmd-anal.</div><div><br></div><div>HTH.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 30, 2014 at 7:15 AM, Jan Stolarek <span dir="ltr"><<a href="mailto:jan.stolarek@p.lodz.pl" target="_blank">jan.stolarek@p.lodz.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm resurrecting this 3-month old thread as I have some more questions about cardinality analysis.<br>
<br>
1. I'm still a bit confused about terminology. Demand analysis, strictness analysis, cardinality<br>
analysis - do these three terms mean exactly the same thing? If no, then what are the<br>
differences?<br>
<br>
2. First pass of full laziness is followed by floating in. At that stage we have not yet run the<br>
demand analysis and yet the code that does the floating-in checks whether a binder is one-shot<br>
(FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam case). This suggests that cardinality<br>
analysis is done earlier (but when?) and that demand analysis is not the same thing as<br>
cardinality analysis.<br>
<br>
3. Does demand analyser perform any transformations? Or does it only annotate Core with demand<br>
information that can be used by subsequent passes?<br>
<br>
4. BasicTypes module defines:<br>
<br>
data OneShotInfo = NoOneShotInfo -- ^ No information<br>
| ProbOneShot -- ^ The lambda is probably applied at most once<br>
| OneShotLam -- ^ The lambda is applied at most once.<br>
<br>
Do I understand correctly that `NoOneShotInfo` really means no information,<br>
ie. a binding annotated with this might in fact be one shot? If so, then do we<br>
have means of saying that a binding is certainly not a one-shot binding?<br>
<br>
5. What is the purpose of SetLevels.lvlMFE function?<br>
<br>
Janek<br>
<br>
> The wiki page just went live:<br>
><br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline</a><br>
><br>
> It's not yet perfect but it should be a good start.<br>
><br>
> > Roughtly, a complete run of the simplifier means "run the simplifier<br>
> > repeatedly until nothing further happens". The iterations are the<br>
> > successive iterations of this loop. Currently there's a (rather arbitrary)<br>
> > limit of four such iterations before we give up and declare victory.<br>
><br>
> A limit or a default value for that limit?<br>
><br>
> To Ilya:<br>
> > If you grep for the "late_dmd_anal" option variable in the compiler/simplCore/SimplCore.lhs<br>
> > module, you'll see that it triggers a phase close to the endo of getCoreToDo's tasks, which<br>
> > contains, in particular, the "CoreDoStrictness" pass. This is the "late" phase.<br>
><br>
> The paper said that the late pass is run to detect single-entry thunks and the reason why it is<br>
> run late in the pipeline is that if it were run earlier this information could be invalidated<br>
> by the transformations. But in the source code I see that this late pass is followed by the<br>
> simplifier, which can invalidate the information. Also, the documentation for -flate-dmd-anal<br>
> says: "We found some opportunities for discovering strictness that were not visible earlier;<br>
> and optimisations like -fspec-constr can create functions with unused arguments which are<br>
> eliminated by late demand analysis". This says nothing about single-netry thunks. So, is the<br>
> single-entry thunk optimisation performed by GHC?<br>
><br>
> Janek<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div>