1. 23 Mar, 2009 3 commits
  2. 03 Apr, 2009 3 commits
    • simonpj@microsoft.com's avatar
      Adjust inlining heursitics · b71760aa
      simonpj@microsoft.com authored
      This patch is the result of a long series of nofib-based experiments
      to improve GHC's inlining heuristics.
      
      In the end, I'm not sure how worthwhile it all was: I only got a 
         1% decrease in code size
         1% decrease in allocation
      and I don't trust the runtime statistics enough to quote.
      
      Still, in doing all this I tidied up the code quite a bit, and 
      I understand it much better now, so I'm going to commit it.
      
      The main changes are in CoreUnfold, which has lots of new comments.
      Other changes:
      
        - litSize moves from Literal to CoreUnfold
        - interestingArg moves from SimplUtils to CoreUnfold
        - the default unfolding threshold (in StaticFlags) 
            reduces from 8 to 6 (since the size calculation 
            has changed a bit)
      
      b71760aa
    • simonpj@microsoft.com's avatar
      Worker/wrapper should make INLINE if it doesn't w/w · 9060e51e
      simonpj@microsoft.com authored
      If worker/wrapper decides not to w/w something on the grounds that
      it's too small, it should add an INLINE pragma.  Otherwise, later
      in the day that small thing might now be big, and we'd wish we'd
      done the w/w after all.  This only made a difference in one nofib 
      program (bspt), but it's an easy change.
      
      See Note [Don't w/w inline things (a) and (b)]
      9060e51e
    • simonpj@microsoft.com's avatar
      Rewrite a good chunk of CoreArity · ea84860e
      simonpj@microsoft.com authored
      I found a couple of shortcomings in arity computation, and did
      quite a bit of refactoring as a result.  Regrettably, I have
      forgotten the details, but I do remember that one part was to
      do with the infamous "state hack".  If we're going to use the
      state-hack at all, we'd better do it right.
      
      Anyway I think this is an improvement. The comments are more
      up to date too, and more voluminous.
      ea84860e
  3. 02 Apr, 2009 7 commits
  4. 30 Mar, 2009 1 commit
  5. 31 Mar, 2009 3 commits
    • Ben.Lippmeier@anu.edu.au's avatar
      SPARC NCG: HpLim is now always stored on the stack, not in a register · 456dc6d6
      Ben.Lippmeier@anu.edu.au authored
         This fixes the out of memory errors we were getting on sparc
         after the following patch:
      
           Fri Mar 13 03:45:16 PDT 2009  Simon Marlow <marlowsd@gmail.com>
           * Instead of a separate context-switch flag, set HpLim to zero
           Ignore-this: 6c5bbe1ce2c5ef551efe98f288483b0
           This reduces the latency between a context-switch being triggered and
           the thread returning to the scheduler, which in turn should reduce the
           cost of the GC barrier when there are many cores. 
      456dc6d6
    • waern's avatar
      Allow Haddock comments in type synonyms · c0778bd3
      waern authored
      We now use `ctypedoc` instead of `ctype` for type synonyms. `ctypedoc` was
      previously only used for top-level type signatures. This change means that type
      synonyms now can contain comments, just like top-level type signatures.
        
      Note:
        
      * I've modified `ctypedoc` so it allows implicit parameters and equational
      constraints, just like ctype.
        
      * Since `ctypedoc` allows nested foralls, we now allow that in type synonyms.
        
      * I have inlined some productions into gentypedoc so that there is now a
      non-doc version of every production with a 'doc' suffix. (Stylistic change
      only, which should make the code easier to follow).
        
      * It would have been nice to simplify the grammar by unifying `ctype` and 
      ctypedoc` into one production, allowing comments on types everywhere (and
      rejecting them after parsing, where necessary).  This is however not possible
      since it leads to ambiguity. The reason is the support for comments on record
      fields:
        
      > data R = R { field :: Int -- ^ comment on the field }
        
      If we allow comments on types here, it's not clear if the comment applies
      to 'field' or to 'Int'. So we must use `ctype` to describe the type.
      c0778bd3
    • Ian Lynagh's avatar
      mkErrorAppDs now takes an SDoc rather than a String · 79b22beb
      Ian Lynagh authored
      This avoids some showSDoc's where the String then gets converted back
      into an SDoc.
      79b22beb
  6. 30 Mar, 2009 7 commits
    • Simon Marlow's avatar
    • simonpj@microsoft.com's avatar
      Fix an nasty black hole, concerning computation of isRecursiveTyCon · 59fa6266
      simonpj@microsoft.com authored
      Fixing #246 (pattern-match order in record patterns) made GHC go into
      a black hole, by changing the order of patterm matching in
      TyCon.isProductTyCon!  It turned out that GHC had been avoiding the
      black hole only by the narrowest of margins up to now!
      
      The black hole concerned the computation of which type constructors
      are recursive, in TcTyDecls.calcRecFlags.  We now refrain from using
      isProductTyCon there, since it triggers the black hole (very
      indirectly).  See the "YUK YUK" comment in the body of calcRecFlags.
      
      As it turns out, the fact that TyCon.isProductTyCon matched on the
      algTcRec field was quite redundant, so I removed that too.  However,
      without the fix to calcRecFlags, this wouldn't fix the black hole
      because of the use of isRecursiveTyCon in BuildTyCl.mkNewTyConRhs.
      
      Anyway, it's fine now.
      59fa6266
    • simonpj@microsoft.com's avatar
      21eea25f
    • simonpj@microsoft.com's avatar
      bc53629a
    • simonpj@microsoft.com's avatar
      Fix Trac #246: order of matching in record patterns · 54e6de85
      simonpj@microsoft.com authored
      While I was looking at the desugaring of pattern matching (fixing
      Trac #3126) I finally got around to fixing another long-standing bug:
      when matching in a record pattern, GHC should match left-to-right in
      the programmer-specfied order, *not* left-to-right positionally in 
      the original record declaration.
      
      Needless to say, that requires a little more code. 
      See Note [Record patterns] in MatchCon.lhs
      
      54e6de85
    • simonpj@microsoft.com's avatar
      Fix Trac #3126: matching overloaded literals · 4da93ad2
      simonpj@microsoft.com authored
      Claus Reinke uncovered a long-standing bug in GHC, whereby we were
      combining the pattern-match on overloaded literals, missing the fact
      that an intervening pattern (for a different literal) might also 
      match.  (If someone had a very odd implementation of fromInteger!)
      
      See Note [Grouping overloaded literal patterns] in Match.lhs
      
      If this merges smoothly to 6.10, go for it, but it's very much
      a corner case.
      
      Thank you Claus!
      4da93ad2
    • simonpj@microsoft.com's avatar
      White space cosmetics only · 5e2dc400
      simonpj@microsoft.com authored
      5e2dc400
  7. 25 Mar, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Improve mkDupableCont; and fix Trac #3116 · 63f6b086
      simonpj@microsoft.com authored
      It turns out that, as a result of a change I made a few months ago to
      the representation of SimplCont, it's easy to solve the optimisation
      challenge posed by Trac #3116.  Hurrah.
      
      Extensive comments in Note [Duplicating StrictArg].
      63f6b086
  8. 23 Mar, 2009 2 commits
  9. 26 Mar, 2009 3 commits
  10. 23 Mar, 2009 1 commit
    • Bertram Felgenhauer's avatar
      update list of C math functions · f7ecb11b
      Bertram Felgenhauer authored
      Fix via C compilation of modules that import, say, log1p from math.h (#3117)
      
      The list is based on preprocessing Stg.h with glibc 2.6.1 headers, and
      cross-checked with the ISO C 99 standard (draft).
      f7ecb11b
  11. 25 Mar, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Template Haskell: make reify aware of type families · 3517c53d
      chak@cse.unsw.edu.au. authored
      - Reifying a type family returns a TH family declaration
      - Reifying a data constructor from a data instance attributes that
        constructor to the family (not the representation tycon)
      - Ideally, we should have facilities to reify all type/data instances of a 
        given family (and the same for instances of a class).  I haven't added that
        here as it involves some API design.
      3517c53d
  12. 24 Mar, 2009 1 commit
  13. 19 Mar, 2009 2 commits
  14. 18 Mar, 2009 3 commits
  15. 17 Mar, 2009 1 commit
  16. 16 Mar, 2009 1 commit