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


Ignore:
Timestamp:
Nov 13, 2006 8:33:54 PM (7 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?