1. 26 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix a long-standing bug the float-out pass · b284d370
      simonpj@microsoft.com authored
      We were failing to float out a binding that could be floated,
      because of a confusion in the Lam case of floatExpr.
      
      In investigating this I also discoverd that there is really
      no point at all in giving a different level to variables in
      a binding group, so I've now given them all the same (in 
      SetLevels.lvlLamBndrs
      
      The overall difference is quite minor in a nofib run:
      
              Program           Size    Allocs   Runtime   Elapsed
      -------------------------------------------------------------
                  Min          +0.0%     -8.5%    -28.4%    -28.7%
                  Max          +0.0%     +0.7%     -0.7%     -1.1%
       Geometric Mean          +0.0%     -0.0%    -11.6%    -11.8%
      
      I don't trust those runtimes, but smaller is good!  The 8.5% 
      improvement in allocation in fulsom, and seems real.  The 
      0.7% allocation increase only happens in programs with
      very small allocation.  I tracked one down to a call of this form
      
        GHC.IO.Handle.Internals.mkDuplexHandle5
          = \ args -> GHC.IO.Handle.Internals.openTextEncoding1
                        mb_codec ha_type
                        (\mb_encoder mb_decoder -> blah)
      
      With the new floater the argument of openTextEncoding1 becomes
      
           (let lvl = .. in \mb_encoder mb_decoder -> blah)
      
      And rightly so.  However in fact this argument is a continuation
      and hence is called once, so the floating is fruitless.
      
      Roll on one-shot-function analysis (which I know how to do
      but fail to get to!).
      b284d370
  2. 31 Aug, 2010 1 commit
  3. 26 Oct, 2010 3 commits
  4. 25 Oct, 2010 5 commits
  5. 24 Oct, 2010 1 commit
  6. 17 Oct, 2010 1 commit
  7. 23 Oct, 2010 5 commits
  8. 22 Oct, 2010 5 commits
  9. 21 Oct, 2010 18 commits