1. 20 Apr, 2009 1 commit
    • Simon Marlow's avatar
      FIX #2845: Allow breakpoints on expressions with unlifted type · 709c9ce0
      Simon Marlow authored
      It turns out we can easily support breakpoints on expressions with
      unlifted types, by translating 
      
        case tick# of _ -> e
      
      into
      
        let f = \s . case tick# of _ -> e 
        in  f realWorld#
      
      instead of just a plain let-binding.  This is the same trick that GHC
      uses for abstracting join points of unlifted type.
      
      In #2845, GHC has eta-expanded the tick expression, changing the
      result type from IO a to (# State#, a #), which was the reason the
      tick was suddenly being ignored.  By supporting ticks on unlifted
      expressions we can make it work again, although some confusion might
      arise because _result will no longer be available (it now has
      unboxed-tuple type, so we can't bind it in the environment).  The
      underlying problem here is that GHC does transformations like
      eta-expanding the tick expressions, and there's nothing we can do to
      prevent that.
      709c9ce0
  2. 03 Apr, 2009 1 commit
  3. 20 Apr, 2009 3 commits
  4. 19 Apr, 2009 1 commit
  5. 18 Apr, 2009 3 commits
  6. 17 Apr, 2009 1 commit
    • waern's avatar
      Simplify the type grammar · ef70af35
      waern authored
      Simon P-J suggested the following simplifications in #3097:
      
      * Allow nested foralls in `ctype` just like in `ctypedoc`.
      * Use `gentype` rather than `type` in the LHS of type declarations.
      * Inline `type` in `ctype`.
      * Rename `gentype` to `type`.
      
      This patch does this. Also, the equivalent thing is done for documented types.
      ef70af35
  7. 13 Apr, 2009 5 commits
  8. 03 Apr, 2009 2 commits
  9. 07 Apr, 2009 1 commit
  10. 09 Apr, 2009 2 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #3155: better error message when -XRankNTypes is omitted · 6c06fdc7
      simonpj@microsoft.com authored
      This patch sligtly re-adjusts the way in which the syntax of types 
      is handled:
      
       * In the lexer, '.' and '*' are always accepted in types
         (previously it was conditional).  This things can't mean
         anything else in H98, which is the only reason for doing things
         conditionally in the lexer.
      
       * As a result '.' in types is never treated as an operator.
         Instead, lacking a 'forall' keyword, it turns into a plain parse error.
      
       * Test for -XKindSignatures in the renamer when processing
           a) type variable bindings
           b) types with sigs (ty :: kind-sig)
      
       * Make -XKindSignatures be implied by -XTypeFamilies 
         Previously this was buried in the conditonal lexing of '*'
      6c06fdc7
    • simonpj@microsoft.com's avatar
  11. 04 Apr, 2009 1 commit
  12. 31 Mar, 2009 2 commits
  13. 03 Apr, 2009 2 commits
    • dias@eecs.tufts.edu's avatar
      eliminate warnings · 82ebc04b
      dias@eecs.tufts.edu authored
      82ebc04b
    • dias@eecs.tufts.edu's avatar
      Debugging by Sesame Street: · dc9db2a8
      dias@eecs.tufts.edu authored
      One of these things is not like the others:
      
      stdPattern :: [LRep] -> Maybe StgHalfWord
      stdPattern reps
        = case reps of
              []  -> Just ARG_NONE    -- just void args, probably
              [N] -> Just ARG_N
              [P] -> Just ARG_N
              [F] -> Just ARG_F
              [D] -> Just ARG_D
              [L] -> Just ARG_L
      
      Today's debugging session was brought to you by the letter P.
      dc9db2a8
  14. 31 Mar, 2009 1 commit
  15. 25 Mar, 2009 1 commit
  16. 23 Mar, 2009 6 commits
  17. 03 Apr, 2009 3 commits
  18. 02 Apr, 2009 2 commits
  19. 03 Apr, 2009 2 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