1. 02 Nov, 2012 2 commits
  2. 09 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Make the opt_UF_* static flags dynamic · 0a768bcb
      ian@well-typed.com authored
      I also removed the default values from the "Discounts and thresholds"
      note: most of them were no longer up-to-date.
      Along the way I added FloatSuffix to the argument parser, analogous to
  3. 23 Aug, 2012 1 commit
  4. 12 Jun, 2012 1 commit
  5. 02 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Allow cases with empty alterantives · ac230c5e
      Simon Peyton Jones authored
      This patch allows, for the first time, case expressions with an empty
      list of alternatives. Max suggested the idea, and Trac #6067 showed
      that it is really quite important.
      So I've implemented the idea, fixing #6067. Main changes
       * See Note [Empty case alternatives] in CoreSyn
       * Various foldr1's become foldrs
       * IfaceCase does not record the type of the alternatives.
         I added IfaceECase for empty-alternative cases.
       * Core Lint does not complain about empty cases
       * MkCore.castBottomExpr constructs an empty-alternative case
         expression   (case e of ty {})
       * CoreToStg converts '(case e of {})' to just 'e'
  6. 09 Nov, 2011 1 commit
  7. 05 Nov, 2011 1 commit
  8. 04 Nov, 2011 1 commit
  9. 02 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Overhaul of infrastructure for profiling, coverage (HPC) and breakpoints · 7bb0447d
      Simon Marlow authored
      User visible changes
      Flags renamed (the old ones are still accepted for now):
        OLD            NEW
        ---------      ------------
        -auto-all      -fprof-auto
        -auto          -fprof-exported
        -caf-all       -fprof-cafs
      New flags:
        -fprof-auto              Annotates all bindings (not just top-level
                                 ones) with SCCs
        -fprof-top               Annotates just top-level bindings with SCCs
        -fprof-exported          Annotates just exported bindings with SCCs
        -fprof-no-count-entries  Do not maintain entry counts when profiling
                                 (can make profiled code go faster; useful with
                                 heap profiling where entry counts are not used)
      Cost-centre stacks have a new semantics, which should in most cases
      result in more useful and intuitive profiles.  If you find this not to
      be the case, please let me know.  This is the area where I have been
      experimenting most, and the current solution is probably not the
      final version, however it does address all the outstanding bugs and
      seems to be better than GHC 7.2.
      Stack traces
      +RTS -xc now gives more information.  If the exception originates from
      a CAF (as is common, because GHC tends to lift exceptions out to the
      top-level), then the RTS walks up the stack and reports the stack in
      the enclosing update frame(s).
      Result: +RTS -xc is much more useful now - but you still have to
      compile for profiling to get it.  I've played around a little with
      adding 'head []' to GHC itself, and +RTS -xc does pinpoint the problem
      quite accurately.
      I plan to add more facilities for stack tracing (e.g. in GHCi) in the
      Coverage (HPC)
       * derived instances are now coloured yellow if they weren't used
       * likewise record field names
       * entry counts are more accurate (hpc --fun-entry-count)
       * tab width is now correct (markup was previously off in source with
      Internal changes
      In Core, the Note constructor has been replaced by
              Tick (Tickish b) (Expr b)
      which is used to represent all the kinds of source annotation we
      support: profiling SCCs, HPC ticks, and GHCi breakpoints.
      Depending on the properties of the Tickish, different transformations
      apply to Tick.  See CoreUtils.mkTick for details.
      This commit closes the following tickets, test cases to follow:
        - Close #2552: not a bug, but the behaviour is now more intuitive
          (test is T2552)
        - Close #680 (test is T680)
        - Close #1531 (test is result001)
        - Close #949 (test is T949)
        - Close #2466: test case has bitrotted (doesn't compile against current
          version of vector-space package)
  10. 08 Sep, 2011 1 commit
  11. 06 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
      this patch adds a new kind Constraint such that:
        Show :: * -> Constraint
        (?x::Int) :: Constraint
        (Int ~ a) :: Constraint
      And you can write *any* type with kind Constraint to the left of (=>):
      even if that type is a type synonym, type variable, indexed type or so on.
      The following (somewhat related) changes are also made:
       1. We now box equality evidence. This is required because we want
          to give (Int ~ a) the *lifted* kind Constraint
       2. For similar reasons, implicit parameters can now only be of
          a lifted kind. (?x::Int#) => ty is now ruled out
       3. Implicit parameter constraints are now allowed in superclasses
          and instance contexts (this just falls out as OK with the new
          constraint solver)
      Internally the following major changes were made:
       1. There is now no PredTy in the Type data type. Instead
          GHC checks the kind of a type to figure out if it is a predicate
       2. There is now no AClass TyThing: we represent classes as TyThings
          just as a ATyCon (classes had TyCons anyway)
       3. What used to be (~) is now pretty-printed as (~#). The box
          constructor EqBox :: (a ~# b) -> (a ~ b)
       4. The type LCoercion is used internally in the constraint solver
          and type checker to represent coercions with free variables
          of type (a ~ b) rather than (a ~# b)
  12. 05 Sep, 2011 2 commits
  13. 03 Aug, 2011 1 commit
  14. 26 May, 2011 1 commit
    • Simon Peyton Jones's avatar
      Suppress the alarming SpecConstr message for normal users (Trac #5125) · 3664c198
      Simon Peyton Jones authored
      This is the offending message:
            Function `$wks2{v s2dJ} [lid]'
              has one call pattern, but the limit is 0
            Use -fspec-constr-count=n to set the bound
            Use -dppr-debug to see specialisations
      The message isn't very good, and is for experts only. So now it
      comes out only
          if you build with -DDEBUG
          or you specify -dppr-debug at runtime
  15. 19 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      This BIG PATCH contains most of the work for the New Coercion Representation · fdf86568
      Simon Peyton Jones authored
      See the paper "Practical aspects of evidence based compilation in System FC"
      * Coercion becomes a data type, distinct from Type
      * Coercions become value-level things, rather than type-level things,
        (although the value is zero bits wide, like the State token)
        A consequence is that a coerion abstraction increases the arity by 1
        (just like a dictionary abstraction)
      * There is a new constructor in CoreExpr, namely Coercion, to inject
        coercions into terms
  16. 07 Feb, 2011 1 commit
  17. 03 Feb, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Fix typo in SpecConstr that made it not work at all · 2a130b13
      simonpj@microsoft.com authored
      There was a terrible typo in this patch; I wrote "env"
      instead of "env1".
         Mon Jan 31 11:35:29 GMT 2011  simonpj@microsoft.com
           * Improve Simplifier and SpecConstr behaviour
      Anyway, this fix is essential to make it work properly.
      Thanks to Max for spotting the problem (again).
  18. 01 Feb, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Some refactoring of SpecConstr · 8287e232
      simonpj@microsoft.com authored
      This was originally to improve the case when SpecConstr generated a
      function with an unused argument (see Trac #4941), but I ended up
      giving up on that.  But the refactoring is still an improvement.
      In particular I got rid of BothOcc, which was unused.
  19. 31 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Improve Simplifier and SpecConstr behaviour · 70ad6e6a
      simonpj@microsoft.com authored
      Trac #4908 identified a case where SpecConstr wasn't "seeing" a
      specialisation it should easily get.  The solution was simple: see
      Note [Add scrutinee to ValueEnv too] in SpecConstr.
      Then it turned out that there was an exactly analogous infelicity in
      the mighty Simplifer too; see Note [Add unfolding for scrutinee] in
      Simplify. This fix is good for Simplify even in the absence of the
      SpecConstr change.  (It arose when I moved the binder- swap stuff to
      OccAnall, not realising that it *remains* valuable to record info
      about the scrutinee of a case expression.  The Note says why.
      Together these two changes are unconditionally good.  Better
      simplification, better specialisation. Thank you Max.
  20. 27 Nov, 2010 1 commit
  21. 25 Nov, 2010 1 commit
  22. 19 Nov, 2010 1 commit
  23. 18 Nov, 2010 2 commits
  24. 17 Nov, 2010 1 commit
  25. 25 Oct, 2010 1 commit
  26. 18 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Define SpecConstrAnnotation in GHC.Exts, and import it from there · 6648babb
      simonpj@microsoft.com authored
      Reason: avoid having to link the entire ghc package in modules
      that use compile-time annotations:
           import GHC.Exts( SpecConstrAnnotation )
           {-# ANN type T ForceSpecConstr #-}
      It's a kind of bug that the package exporting SpecConstrAnnotation
      is linked even though it is only needed at compile time, but putting
      the data type declaration in GHC.Exts is a simple way to sidestep
      the problem
      See See Note [SpecConstrAnnotation] in SpecConstr
  27. 07 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Implement auto-specialisation of imported Ids · 92267aa2
      simonpj@microsoft.com authored
      This big-ish patch arranges that if an Id 'f' is 
        * Type-class overloaded 
             f :: Ord a => [a] -> [a]
        * Defined with an INLINABLE pragma
             {-# INLINABLE f #-}
        * Exported from its defining module 'D'
      then in any module 'U' that imports D
      1. Any call of 'f' at a fixed type will generate 
         (a) a specialised version of f in U
         (b) a RULE that rewrites unspecialised calls to the
             specialised on
        e.g. if the call is (f Int dOrdInt xs) then the 
        specialiser will generate
           $sfInt :: [Int] -> [Int]
           $sfInt = <code for f, imported from D, specialised>
           {-# RULE forall d.  f Int d = $sfInt #-}
      2. In addition, you can give an explicit {-# SPECIALISE -#}
         pragma for the imported Id
           {-# SPECIALISE f :: [Bool] -> [Bool] #-}
         This too generates a local specialised definition, 
         and the corresponding RULE 
      The new RULES are exported from module 'U', so that any module
      importing U will see the specialised versions of 'f', and will
      not re-specialise them.
      There's a flag -fwarn-auto-orphan that warns you if the auto-generated
      RULES are orphan rules. It's not in -Wall, mainly to avoid lots of
      error messages with existing packages.
      Main implementation changes
       - A new flag on a CoreRule to say if it was auto-generated.
         This is persisted across interface files, so there's a small
         change in interface file format.
       - Quite a bit of fiddling with plumbing, to get the 
         {-# SPECIALISE #-} pragmas for imported Ids.  In particular, a
         new field tgc_imp_specs in TcGblEnv, to keep the specialise
         pragmas for imported Ids between the typechecker and the desugarer.
       - Some new code (although surprisingly little) in Specialise,
         to deal with calls of imported Ids
  28. 14 Sep, 2010 1 commit
  29. 13 Sep, 2010 1 commit
  30. 25 May, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Don't do SpecConstr on NOINLINE things (Trac #4064) · f03b9562
      simonpj@microsoft.com authored
      Since the RULE from specialising gets the same Activation as
      the inlining for the Id itself there's no point in specialising
      a NOINLINE thing, because the rule will be permanently switched
      See Note [Transfer activation] in SpecConstr
      and Note [Auto-specialisation and RULES] in Specialise.
  31. 05 May, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Matching cases in SpecConstr and Rules · 9abe2972
      simonpj@microsoft.com authored
      This patch has zero effect.  It includes comments,
      a bit of refactoring, and a tiny bit of commment-out
      code go implement the "matching cases" idea below.
      In the end I've left it disabled because while I think
      it does no harm I don't think it'll do any good either.
      But I didn't want to lose the idea totally. There's
      a thread called "Storable and constant memory" on
      the libraries@haskell.org list (Apr 2010) about it.
      Note [Matching cases]
      {- NOTE: This idea is currently disabled.  It really only works if
               the primops involved are OkForSpeculation, and, since
      	 they have side effects readIntOfAddr and touch are not.
      	 Maybe we'll get back to this later .  -}
         f (case readIntOffAddr# p# i# realWorld# of { (# s#, n# #) ->
            case touch# fp s# of { _ -> 
            I# n# } } )
      This happened in a tight loop generated by stream fusion that 
      Roman encountered.  We'd like to treat this just like the let 
      case, because the primops concerned are ok-for-speculation.
      That is, we'd like to behave as if it had been
         case readIntOffAddr# p# i# realWorld# of { (# s#, n# #) ->
         case touch# fp s# of { _ -> 
         f (I# n# } } )
  32. 09 Apr, 2010 1 commit
  33. 20 Mar, 2010 1 commit
  34. 15 Feb, 2010 2 commits
  35. 10 Feb, 2010 1 commit
  36. 01 Feb, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3831: blowup in SpecConstr · 13c66820
      simonpj@microsoft.com authored
      It turned out that there were two bugs.  First, we were getting an
      exponential number of specialisations when we had a deep nest of
      join points.  See Note [Avoiding exponential blowup]. I fixed this
      by dividing sc_count (in ScEnv) by the number of specialisations
      when recursing.  Crude but effective.
      Second, when making specialisations I was looking at the result of
      applying specExpr to the RHS of the function, whereas I should have
      been looking at the original RHS.  See Note [Specialise original
      There's a tantalising missed opportunity here, though.  In this
      example (recorded as a test simplCore/should_compile/T3831), each join
      point has *exactly one* call pattern, so we should really just
      specialise for that alone, in which case there's zero code-blow-up.
      In particular, we don't need the *original* RHS at all.  I need to think
      more about how to exploit this.
      But the blowup is now limited, so compiling terminfo with -O2 works again.