1. 22 Oct, 2011 3 commits
  2. 21 Oct, 2011 6 commits
    • Simon Peyton Jones's avatar
      Recover proper sharing for Integer literals · ca380cd1
      Simon Peyton Jones authored
      Trac #5549 showed a loss of performance for GHC 7.4.
      What was happening was that an integer literal was being
      allocated each time around a loop, rather than being
      floated to top level and shared.
      
      Two fixes
       * Make the float-out pass float literals that are non-trivial
       * Make the inliner *not* treat Integer literals as size-zero
      ca380cd1
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      d242c87d
    • Simon Peyton Jones's avatar
      Refactor the way in which type (and other) signatures are renamed · 8f3f4178
      Simon Peyton Jones authored
      This was a trickier change than I had anticipated, but I think
      it's considerably tidier now.
      
      Fixes Trac #5533.
      8f3f4178
    • Simon Peyton Jones's avatar
      Be even more careful about eta expansion when bottom is involved · 6d5dfbf7
      Simon Peyton Jones authored
      See Note [Dealing with bottom], reproduced below.  Fixes Trac #5557.
      
      3.  Note [Dealing with bottom]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Consider
      	f = \x -> error "foo"
      Here, arity 1 is fine.  But if it is
      	f = \x -> case x of
      			True  -> error "foo"
      			False -> \y -> x+y
      then we want to get arity 2.  Technically, this isn't quite right, because
      	(f True) `seq` 1
      should diverge, but it'll converge if we eta-expand f.  Nevertheless, we
      do so; it improves some programs significantly, and increasing convergence
      isn't a bad thing.  Hence the ABot/ATop in ArityType.
      
      However, this really isn't always the Right Thing, and we have several
      tickets reporting unexpected bahaviour resulting from this
      transformation.  So we try to limit it as much as possible:
      
       * Do NOT move a lambda outside a known-bottom case expression
            case undefined of { (a,b) -> \y -> e }
         This showed up in Trac #5557
      
       * Do NOT move a lambda outside a case if all the branches of
         the case are known to return bottom.
            case x of { (a,b) -> \y -> error "urk" }
         This case is less important, but the idea is that if the fn is
         going to diverge eventually anyway then getting the best arity
         isn't an issue, so we might as well play safe
      
      Of course both these are readily defeated by disguising the bottoms.
      6d5dfbf7
  3. 20 Oct, 2011 4 commits
  4. 19 Oct, 2011 12 commits
  5. 18 Oct, 2011 12 commits
  6. 17 Oct, 2011 3 commits