1. 23 Oct, 2011 10 commits
  2. 22 Oct, 2011 3 commits
  3. 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
  4. 20 Oct, 2011 4 commits
  5. 19 Oct, 2011 12 commits
  6. 18 Oct, 2011 5 commits
    • dterei's avatar
      Fix warning. · 53f14145
      dterei authored
      53f14145
    • dterei's avatar
      78df9af0
    • dterei's avatar
      Fix file permissions · 077c2072
      dterei authored
      077c2072
    • Ian Lynagh's avatar
      Remove ArchUnknown · 2dea11a4
      Ian Lynagh authored
      It doesn't make sense. If platformArch is ArchUnknown then we don't know
      the answer to any questions about the arch. So now if we don't recognise
      the arch we just fail, and the new arch will need to be added to the
      datatype.
      2dea11a4
    • Ian Lynagh's avatar
      Remove OSUnknown · f75f26cc
      Ian Lynagh authored
      It doesn't make sense. If platformOS is OSUnknown then we don't know the
      answer to any questions about the OS. So now if we don't recognise the
      OS we just fail, and the new OS will need to be added to the datatype.
      f75f26cc