This project is mirrored from Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 04 May, 2012 1 commit
  2. 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'
  3. 27 Apr, 2012 3 commits
  4. 30 Mar, 2012 1 commit
  5. 21 Mar, 2012 1 commit
    • batterseapower's avatar
      Make impossible-alternative-finding code more reusable · aecacda1
      batterseapower authored
      Makes the following changes:
       1. Generalises the type signatures of some functions relating to alternatives
          so that the type of "variables" and "expression" is not specified
       2. Puts the bulk of the alternative-filtering code into a new function filterAlts
          (in CoreUtils) that can be used outside of the SimplM monad
       3. Allows prepareAlts to return a null alternatives list if none are applicable -
          it turns out that this case was already handled by the caller (in the simplifier).
          This should result in a modest optimisation improvement in some cases.
  6. 17 Feb, 2012 1 commit
  7. 19 Jan, 2012 1 commit
  8. 16 Jan, 2012 1 commit
  9. 13 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Add -faggressive-primops plus refactoring in CoreUtils · 601c983d
      Simon Peyton Jones authored
      I'm experimenting with making GHC a bit more aggressive about
        a) dropping case expressions if the result is unused
              Simplify.rebuildCase, CaseElim equation
        b) floating case expressions inwards
              FloatIn.fiExpr, AnnCase
      In both cases the new behaviour is gotten with a static (debug)
      flag -faggressive-primops.  The extra "aggression" is to allow
      discarding and floating in for side-effecting operations.  See
      the new, extensive Note [PrimOp can_fail and has_side_effects]
      in PrimoOp.
      When discarding a case with unused binders, in the lifted-type
      case it's definitely ok if the scrutinee terminates; previously
      we were checking exprOkForSpeculation, which is significantly
      So I wanted a new function CoreUtils.exprCertainlyTerminates.
      In doing this I ended up with a significant refactoring in
      CoreUtils.  The new structure has quite a lot of nice sharing:
          exprIsCheap             = exprIsCheap' isHNFApp
          exprIsExpandable        = exprIsCheap' isConLikeApp
          exprIsHNF               = exprIsHNFlike isHNFApp
          exprIsConLike           = exprIsHNFlike isConLikeApp
          exprCertainlyTerminates = exprIsHNFlike isTerminatingApp
  10. 16 Nov, 2011 3 commits
  11. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 09015be8
      dreixel authored
      This big patch implements a kind-polymorphic core for GHC. The current
      implementation focuses on making sure that all kind-monomorphic programs still
      work in the new core; it is not yet guaranteed that kind-polymorphic programs
      (using the new -XPolyKinds flag) will work.
      For more information, see
  12. 09 Nov, 2011 1 commit
    • Simon Peyton Jones's avatar
      Fix Trac #5475: another bug in exprArity · b8abb31f
      Simon Peyton Jones authored
      As usual it was to do with the handling of bottoms,
      but this time it wasn't terribly subtle; I was using
      andArityType (which is designed for case branches) as
      a cheap short cut for the arity trimming needed with
      a cast.  That did the Wrong Thing for bottoming
      expressions.  Sigh.
  13. 04 Nov, 2011 1 commit
  14. 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)
  15. 01 Aug, 2011 1 commit
  16. 21 Jul, 2011 2 commits
    • Simon Peyton Jones's avatar
      Eta expand partial applications · 0971055c
      Simon Peyton Jones authored
      When we have
           x = \v -> map g
      we want to eta-expand to
           x = \v y -> map g y
      We weren't doing so, and that led to worse code and,
      perhaps, #5285.  I need to check the latter, but I
      was certainly seeing one similar error.  Anyway
      this looks like a definite improvement
    • Simon Peyton Jones's avatar
      Simplify the treatment of RULES in OccurAnal · f88b20f4
      Simon Peyton Jones authored
      I realised that my recently-added cunning stuff about
      RULES for imported Ids was simply wrong, so this patch
      removes it.   See Note [Rules for imported functions],
      which explains it all.
      This patch also does quite a bit of refactoring in
      the treatment of loop breakers.
  17. 12 May, 2011 1 commit
    • Simon Peyton Jones's avatar
      The final batch of changes for the new coercion representation · c8c2f6bb
      Simon Peyton Jones authored
      * Fix bugs in the packing and unpacking of data
        constructors with equality predicates in their types
      * Remove PredCo altogether; instead, coercions between predicated
        types (like  (Eq a, [a]~b) => blah) are treated as if they
        were precisely their underlying representation type
             Eq a -> ((~) [a] b) -> blah
        in this case
      * Similarly, Type.coreView no longer treats equality
        predciates specially.
      * Implement the cast-of-coercion optimisation in
      Numerous other small bug-fixes and refactorings.
      Annoyingly, OptCoercion had Windows line endings, and this
      patch switches to Unix, so it looks as if every line has changed.
  18. 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
  19. 14 Jan, 2011 1 commit
    •'s avatar
      Fix a buglet in postInlineUnconditionally · 3bb32454 authored
      Under obscure circumstances (actually only shown up when fixing something
      else) it was possible for a variable binding to be discarded although
      it was still used.  See Note [Top level and postInlineUnconditionally]
  20. 21 Dec, 2010 1 commit
    •'s avatar
      Add a simple arity analyser · 1d7a3cf3 authored
      I've wanted to do this for ages, but never gotten around to
      it.  The main notes are in Note [Arity analysis] in SimplUtils.
      The motivating example for arity analysis is this:
        f = \x. let g = f (x+1)
                in \y. ...g...
      What arity does f have?  Really it should have arity 2, but a naive
      look at the RHS won't see that.  You need a fixpoint analysis which
      says it has arity "infinity" the first time round.
      This makes things more robust to the way in which you write code.  For
      example, see Trac #4474 which is fixed by this change.
      Not a huge difference, but worth while:
              Program           Size    Allocs   Runtime   Elapsed
                  Min          -0.4%     -2.2%    -10.0%    -10.0%
                  Max          +2.7%     +0.3%     +7.1%     +6.9%
       Geometric Mean          -0.3%     -0.2%     -2.1%     -2.2%
      I don't really believe the runtime numbers, because the machine was
      busy, but the bottom line is that not much changes, and what does
      change reliably (allocation and size) is in the right direction.
  21. 02 Mar, 2011 1 commit
  22. 16 Nov, 2010 1 commit
    •'s avatar
      Refactoring of the way that inlinings and rules are activated · c177e43f authored
      Principally, the SimplifierMode now carries several (currently
      four) flags in *all* phases, not just the "Gentle" phase.
      This makes things simpler and more uniform.
      As usual I did more refactoring than I had intended.
      This stuff should go into 7.0.2 in due course, once
      we've checked it solves the DPH performance problems.
  23. 27 Oct, 2010 1 commit
    •'s avatar
      Two signficant changes to the simplifier · f95a9542 authored
      1. Do eta-expansion at let-bindings, not lambdas.
         I have wanted to do this for a long time.
         See Note [Eta-expanding at let bindings] in SimplUtils
      2. Simplify the rather subtle way in which InlineRules (the
         template captured by an INLINE pragma) was simplified.
         Now, these templates are always simplified in "gentle"
         mode only, and only INLINE things inline inside them.
         See Note Note [Gentle mode], Note [Inlining in gentle mode]
         and Note [RULEs enabled in SimplGently] in SimplUtils
  24. 07 Oct, 2010 1 commit
    •'s avatar
      Avoid redundant simplification · fb982282 authored
      When adding specialisation for imported Ids, I noticed that the
      Glorious Simplifier was repeatedly (and fruitlessly) simplifying the
      same term.  It turned out to be easy to fix this, because I already
      had a flag in the ApplyTo and Select constructors of SimplUtils.SimplCont.
      See Note [Avoid redundant simplification]
  25. 24 Sep, 2010 1 commit
  26. 13 Sep, 2010 1 commit
  27. 27 Jul, 2010 1 commit
  28. 12 Aug, 2010 1 commit
  29. 23 Apr, 2010 1 commit
  30. 05 Mar, 2010 1 commit
  31. 05 Jan, 2010 1 commit
  32. 24 Dec, 2009 1 commit
  33. 18 Dec, 2009 1 commit
    •'s avatar
      Move all the CoreToDo stuff into CoreMonad · 63e3a411 authored
      This patch moves a lot of code around, but has zero functionality change.
      The idea is that the types
          the main core-to-core pipeline construction
      belong in simplCore/, and *not* in DynFlags.
  34. 16 Dec, 2009 2 commits
    •'s avatar
      Adjust Activations for specialise and work/wrap, and better simplify in InlineRules · 76dfa394 authored
      This patch does two main things:
      1. Adjusts the way we set the Activation for
         a) The wrappers generated by the strictness analyser
            See Note [Wrapper activation] in WorkWrap
         b) The RULEs generated by Specialise and SpecConstr
            See Note [Auto-specialisation and RULES] in Specialise
                Note [Transfer activation] in SpecConstr
      2. Refines how we set the phase when simplifying the right
         hand side of an InlineRule.  See
         Note [Simplifying inside InlineRules] in SimplUtils.
      Most of the extra lines are comments!  
      The merit of (2) is that a bit more stuff happens inside InlineRules,
      and that in turn allows better dead-code elimination.
    •'s avatar
      Comments only · 455302c1 authored