Changes between Version 16 and Version 17 of Commentary/Compiler/StrictnessAnalysis/KirstenNotes


Ignore:
Timestamp:
Nov 13, 2006 8:33:54 PM (9 years ago)
Author:
kirsten
Comment:

strictness and let-floating

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/StrictnessAnalysis/KirstenNotes

    v16 v17  
    5757
    5858In {{{emitBlackHoleCode}}} in [[GhcFile(compiler/codeGen/CgClosure.lhs)]], "eager blackholing" was getting employed in the case where ticky was turned on; this was causing programs to {{{<<loop>>}}} when they wouldn't with ticky disabled, so I turned that off.
     59
     60= Strictness and let-floating =
     61
     62We run into the following problem in the {{{transform}}} nofib benchmark: suppose we have:
     63{{{
     64f x =
     65  let foo = stuff in
     66     foo + x
     67}}}
     68where {{{stuff}}} doesn't depend on {{{x}}}. Demand analysis says that {{{foo}}} has a strict demand placed on it. Later, {{{foo}}} gets floated to the top level because it doesn't depend on {{{x}}} (in reality it's more complicated because in this case {{{foo}}} probably would have gotten floated out before demand analysis, but bear with me). {{{foo}}} still has a strict demand signature, which a top-level binding isn't allowed to have. Currently this manifests itself as an assertion failure in [[GhcFile(compiler/simplCore/SimplEnv.lhs)]].
     69
     70There are two possible easy solutions: don't float out bindings for strict things, or "both" the demand for a binder with Lazy when its binding gets floated out. The question is, is it better to do the let-floating and lose the strictness into or to evaluate something strictly but lose sharing?