1. 23 Jul, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3193: improve line number reporting for equality constraints · 9091712c
      simonpj@microsoft.com authored
      When reporting an error from a failed equality constraint, we were
      setting the *context* but not the *line number* in TcTyFuns.eqInstMisMatch
      As a result, the line number didn't match the context at all.  It's
      trivial to fix.
      
      I'm 99% certain this fixes #3193, but it's too complicated to
      reproduce, so I have not actually tested it.
      9091712c
  2. 17 Jul, 2009 1 commit
  3. 07 Jul, 2009 1 commit
  4. 01 Jul, 2009 1 commit
  5. 28 May, 2009 2 commits
  6. 27 Apr, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Equality constraint solver is now externally pure · 296058a1
      chak@cse.unsw.edu.au. authored
      - This patch changes the equality constraint solver such that it does not
        instantiate any type variables that occur in the constraints that are to be
        solved (or in the environment).  Instead, it returns a bag of type bindings.
      - If these type bindings (together with the other results of the solver) are
        discarded, solver invocation has no effect (outside the solver) and can be
        repeated (that's imported for TcSimplifyRestricted).
      - For the type bindings to take effect, the caller of the solver needs to 
        execute them. 
      - The solver will still instantiate type variables thet were created during 
        solving (e.g., skolem flexibles used during type flattening).
      
        See also http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsSolving
      296058a1
  7. 03 Mar, 2009 1 commit
  8. 11 Feb, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3017: ensure that we quantify over enough type variables when equalities are involved · e5a8d57c
      simonpj@microsoft.com authored
      The function FunDeps.grow was not doing the right thing when type equality
      constraints were involved.  That wasn't really its fault: its input was
      being filtered by fdPredsOfInsts.
      
      To fix this I did a bit of refactoring, so that the (revolting) fdPredsOfInsts
      is now less important (maybe we can get rid of it in due course).  The 'grow'
      function moves from FunDeps to
      	 Inst.growInstsTyVars
      	 TcMTType.growThetaTyVars
      	 TcMType.growTyVars
      
      The main comments are with the first of these, in
      Note [Growing the tau-tvs using constraints] in Inst.
      
      Push to the branch if conflict free.
      
      e5a8d57c
  9. 30 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #2985: generating superclasses and recursive dictionaries · c04a5fe3
      simonpj@microsoft.com authored
      The Note [Recursive instances and superclases] explains the subtle
      issues to do with generating the bindings for superclasses when
      we compile an instance declaration, at least if we want to do the
      clever "recursive superclass" idea from the SYB3 paper.
      
      The old implementation of tcSimplifySuperClasses stumbled when
      type equalities entered the picture (details in the Note); this
      patch fixes the problem using a slightly hacky trick.  When we
      re-engineer the constraint solver we'll want to keep an eye on 
      this.
      
      Probably worth merging to the 6.10 branch.
      
      c04a5fe3
  10. 31 Dec, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Improve error reporting for 'deriving' · 9b69d74f
      simonpj@microsoft.com authored
      a) Improve the extra suggested fix when there's a "no instance"
         error in a deriving clause.
      
      b) Improve error location recording in tcInstDecl2
      
      Many of the changes in tcInstDecl2 are simple reformatting.
      
      9b69d74f
  11. 16 Dec, 2008 1 commit
    • Simon Marlow's avatar
      Rollback INLINE patches · e79c9ce0
      Simon Marlow authored
      rolling back:
      
      Fri Dec  5 16:54:00 GMT 2008  simonpj@microsoft.com
        * Completely new treatment of INLINE pragmas (big patch)
        
        This is a major patch, which changes the way INLINE pragmas work.
        Although lots of files are touched, the net is only +21 lines of
        code -- and I bet that most of those are comments!
        
        HEADS UP: interface file format has changed, so you'll need to
        recompile everything.
        
        There is not much effect on overall performance for nofib, 
        probably because those programs don't make heavy use of INLINE pragmas.
        
                Program           Size    Allocs   Runtime   Elapsed
                    Min         -11.3%     -6.9%     -9.2%     -8.2%
                    Max          -0.1%     +4.6%     +7.5%     +8.9%
         Geometric Mean          -2.2%     -0.2%     -1.0%     -0.8%
        
        (The +4.6% for on allocs is cichelli; see other patch relating to
        -fpass-case-bndr-to-join-points.)
        
        The old INLINE system
        ~~~~~~~~~~~~~~~~~~~~~
        The old system worked like this. A function with an INLINE pragam
        got a right-hand side which looked like
             f = __inline_me__ (\xy. e)
        The __inline_me__ part was an InlineNote, and was treated specially
        in various ways.  Notably, the simplifier didn't inline inside an
        __inline_me__ note.  
        
        As a result, the code for f itself was pretty crappy. That matters
        if you say (map f xs), because then you execute the code for f,
        rather than inlining a copy at the call site.
        
        The new story: InlineRules
        ~~~~~~~~~~~~~~~~~~~~~~~~~~
        The new system removes the InlineMe Note altogether.  Instead there
        is a new constructor InlineRule in CoreSyn.Unfolding.  This is a 
        bit like a RULE, in that it remembers the template to be inlined inside
        the InlineRule.  No simplification or inlining is done on an InlineRule,
        just like RULEs.  
        
        An Id can have an InlineRule *or* a CoreUnfolding (since these are two
        constructors from Unfolding). The simplifier treats them differently:
        
          - An InlineRule is has the substitution applied (like RULES) but 
            is otherwise left undisturbed.
        
          - A CoreUnfolding is updated with the new RHS of the definition,
            on each iteration of the simplifier.
        
        An InlineRule fires regardless of size, but *only* when the function
        is applied to enough arguments.  The "arity" of the rule is specified
        (by the programmer) as the number of args on the LHS of the "=".  So
        it makes a difference whether you say
          	{-# INLINE f #-}
        	f x = \y -> e     or     f x y = e
        This is one of the big new features that InlineRule gives us, and it
        is one that Roman really wanted.
        
        In contrast, a CoreUnfolding can fire when it is applied to fewer
        args than than the function has lambdas, provided the result is small
        enough.
        
        
        Consequential stuff
        ~~~~~~~~~~~~~~~~~~~
        * A 'wrapper' no longer has a WrapperInfo in the IdInfo.  Instead,
          the InlineRule has a field identifying wrappers.
        
        * Of course, IfaceSyn and interface serialisation changes appropriately.
        
        * Making implication constraints inline nicely was a bit fiddly. In
          the end I added a var_inline field to HsBInd.VarBind, which is why
          this patch affects the type checker slightly
        
        * I made some changes to the way in which eta expansion happens in
          CorePrep, mainly to ensure that *arguments* that become let-bound
          are also eta-expanded.  I'm still not too happy with the clarity
          and robustness fo the result.
        
        * We now complain if the programmer gives an INLINE pragma for
          a recursive function (prevsiously we just ignored it).  Reason for
          change: we don't want an InlineRule on a LoopBreaker, because then
          we'd have to check for loop-breaker-hood at occurrence sites (which
          isn't currenlty done).  Some tests need changing as a result.
        
        This patch has been in my tree for quite a while, so there are
        probably some other minor changes.
        
      
          M ./compiler/basicTypes/Id.lhs -11
          M ./compiler/basicTypes/IdInfo.lhs -82
          M ./compiler/basicTypes/MkId.lhs -2 +2
          M ./compiler/coreSyn/CoreFVs.lhs -2 +25
          M ./compiler/coreSyn/CoreLint.lhs -5 +1
          M ./compiler/coreSyn/CorePrep.lhs -59 +53
          M ./compiler/coreSyn/CoreSubst.lhs -22 +31
          M ./compiler/coreSyn/CoreSyn.lhs -66 +92
          M ./compiler/coreSyn/CoreUnfold.lhs -112 +112
          M ./compiler/coreSyn/CoreUtils.lhs -185 +184
          M ./compiler/coreSyn/MkExternalCore.lhs -1
          M ./compiler/coreSyn/PprCore.lhs -4 +40
          M ./compiler/deSugar/DsBinds.lhs -70 +118
          M ./compiler/deSugar/DsForeign.lhs -2 +4
          M ./compiler/deSugar/DsMeta.hs -4 +3
          M ./compiler/hsSyn/HsBinds.lhs -3 +3
          M ./compiler/hsSyn/HsUtils.lhs -2 +7
          M ./compiler/iface/BinIface.hs -11 +25
          M ./compiler/iface/IfaceSyn.lhs -13 +21
          M ./compiler/iface/MkIface.lhs -24 +19
          M ./compiler/iface/TcIface.lhs -29 +23
          M ./compiler/main/TidyPgm.lhs -55 +49
          M ./compiler/parser/ParserCore.y -5 +6
          M ./compiler/simplCore/CSE.lhs -2 +1
          M ./compiler/simplCore/FloatIn.lhs -6 +1
          M ./compiler/simplCore/FloatOut.lhs -23
          M ./compiler/simplCore/OccurAnal.lhs -36 +5
          M ./compiler/simplCore/SetLevels.lhs -59 +54
          M ./compiler/simplCore/SimplCore.lhs -48 +52
          M ./compiler/simplCore/SimplEnv.lhs -26 +22
          M ./compiler/simplCore/SimplUtils.lhs -28 +4
          M ./compiler/simplCore/Simplify.lhs -91 +109
          M ./compiler/specialise/Specialise.lhs -15 +18
          M ./compiler/stranal/WorkWrap.lhs -14 +11
          M ./compiler/stranal/WwLib.lhs -2 +2
          M ./compiler/typecheck/Inst.lhs -1 +3
          M ./compiler/typecheck/TcBinds.lhs -17 +27
          M ./compiler/typecheck/TcClassDcl.lhs -1 +2
          M ./compiler/typecheck/TcExpr.lhs -4 +6
          M ./compiler/typecheck/TcForeign.lhs -1 +1
          M ./compiler/typecheck/TcGenDeriv.lhs -14 +13
          M ./compiler/typecheck/TcHsSyn.lhs -3 +2
          M ./compiler/typecheck/TcInstDcls.lhs -5 +4
          M ./compiler/typecheck/TcRnDriver.lhs -2 +11
          M ./compiler/typecheck/TcSimplify.lhs -10 +17
          M ./compiler/vectorise/VectType.hs +7
      
      Mon Dec  8 12:43:10 GMT 2008  simonpj@microsoft.com
        * White space only
      
          M ./compiler/simplCore/Simplify.lhs -2
      
      Mon Dec  8 12:48:40 GMT 2008  simonpj@microsoft.com
        * Move simpleOptExpr from CoreUnfold to CoreSubst
      
          M ./compiler/coreSyn/CoreSubst.lhs -1 +87
          M ./compiler/coreSyn/CoreUnfold.lhs -72 +1
      
      Mon Dec  8 17:30:18 GMT 2008  simonpj@microsoft.com
        * Use CoreSubst.simpleOptExpr in place of the ad-hoc simpleSubst (reduces code too)
      
          M ./compiler/deSugar/DsBinds.lhs -50 +16
      
      Tue Dec  9 17:03:02 GMT 2008  simonpj@microsoft.com
        * Fix Trac #2861: bogus eta expansion
        
        Urghlhl!  I "tided up" the treatment of the "state hack" in CoreUtils, but
        missed an unexpected interaction with the way that a bottoming function
        simply swallows excess arguments.  There's a long
             Note [State hack and bottoming functions]
        to explain (which accounts for most of the new lines of code).
        
      
          M ./compiler/coreSyn/CoreUtils.lhs -16 +53
      
      Mon Dec 15 10:02:21 GMT 2008  Simon Marlow <marlowsd@gmail.com>
        * Revert CorePrep part of "Completely new treatment of INLINE pragmas..."
        
        The original patch said:
        
        * I made some changes to the way in which eta expansion happens in
          CorePrep, mainly to ensure that *arguments* that become let-bound
          are also eta-expanded.  I'm still not too happy with the clarity
          and robustness fo the result.
          
        Unfortunately this change apparently broke some invariants that were
        relied on elsewhere, and in particular lead to panics when compiling
        with profiling on.
        
        Will re-investigate in the new year.
      
          M ./compiler/coreSyn/CorePrep.lhs -53 +58
          M ./configure.ac -1 +1
      
      Mon Dec 15 12:28:51 GMT 2008  Simon Marlow <marlowsd@gmail.com>
        * revert accidental change to configure.ac
      
          M ./configure.ac -1 +1
      e79c9ce0
  12. 05 Dec, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Completely new treatment of INLINE pragmas (big patch) · d95ce839
      simonpj@microsoft.com authored
      This is a major patch, which changes the way INLINE pragmas work.
      Although lots of files are touched, the net is only +21 lines of
      code -- and I bet that most of those are comments!
      
      HEADS UP: interface file format has changed, so you'll need to
      recompile everything.
      
      There is not much effect on overall performance for nofib, 
      probably because those programs don't make heavy use of INLINE pragmas.
      
              Program           Size    Allocs   Runtime   Elapsed
                  Min         -11.3%     -6.9%     -9.2%     -8.2%
                  Max          -0.1%     +4.6%     +7.5%     +8.9%
       Geometric Mean          -2.2%     -0.2%     -1.0%     -0.8%
      
      (The +4.6% for on allocs is cichelli; see other patch relating to
      -fpass-case-bndr-to-join-points.)
      
      The old INLINE system
      ~~~~~~~~~~~~~~~~~~~~~
      The old system worked like this. A function with an INLINE pragam
      got a right-hand side which looked like
           f = __inline_me__ (\xy. e)
      The __inline_me__ part was an InlineNote, and was treated specially
      in various ways.  Notably, the simplifier didn't inline inside an
      __inline_me__ note.  
      
      As a result, the code for f itself was pretty crappy. That matters
      if you say (map f xs), because then you execute the code for f,
      rather than inlining a copy at the call site.
      
      The new story: InlineRules
      ~~~~~~~~~~~~~~~~~~~~~~~~~~
      The new system removes the InlineMe Note altogether.  Instead there
      is a new constructor InlineRule in CoreSyn.Unfolding.  This is a 
      bit like a RULE, in that it remembers the template to be inlined inside
      the InlineRule.  No simplification or inlining is done on an InlineRule,
      just like RULEs.  
      
      An Id can have an InlineRule *or* a CoreUnfolding (since these are two
      constructors from Unfolding). The simplifier treats them differently:
      
        - An InlineRule is has the substitution applied (like RULES) but 
          is otherwise left undisturbed.
      
        - A CoreUnfolding is updated with the new RHS of the definition,
          on each iteration of the simplifier.
      
      An InlineRule fires regardless of size, but *only* when the function
      is applied to enough arguments.  The "arity" of the rule is specified
      (by the programmer) as the number of args on the LHS of the "=".  So
      it makes a difference whether you say
        	{-# INLINE f #-}
      	f x = \y -> e     or     f x y = e
      This is one of the big new features that InlineRule gives us, and it
      is one that Roman really wanted.
      
      In contrast, a CoreUnfolding can fire when it is applied to fewer
      args than than the function has lambdas, provided the result is small
      enough.
      
      
      Consequential stuff
      ~~~~~~~~~~~~~~~~~~~
      * A 'wrapper' no longer has a WrapperInfo in the IdInfo.  Instead,
        the InlineRule has a field identifying wrappers.
      
      * Of course, IfaceSyn and interface serialisation changes appropriately.
      
      * Making implication constraints inline nicely was a bit fiddly. In
        the end I added a var_inline field to HsBInd.VarBind, which is why
        this patch affects the type checker slightly
      
      * I made some changes to the way in which eta expansion happens in
        CorePrep, mainly to ensure that *arguments* that become let-bound
        are also eta-expanded.  I'm still not too happy with the clarity
        and robustness fo the result.
      
      * We now complain if the programmer gives an INLINE pragma for
        a recursive function (prevsiously we just ignored it).  Reason for
        change: we don't want an InlineRule on a LoopBreaker, because then
        we'd have to check for loop-breaker-hood at occurrence sites (which
        isn't currenlty done).  Some tests need changing as a result.
      
      This patch has been in my tree for quite a while, so there are
      probably some other minor changes.
      d95ce839
  13. 30 Oct, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add (a) CoreM monad, (b) new Annotations feature · 9bcd95ba
      simonpj@microsoft.com authored
      This patch, written by Max Bolingbroke,  does two things
      
      1.  It adds a new CoreM monad (defined in simplCore/CoreMonad),
          which is used as the top-level monad for all the Core-to-Core
          transformations (starting at SimplCore).  It supports
             * I/O (for debug printing)
             * Unique supply
             * Statistics gathering
             * Access to the HscEnv, RuleBase, Annotations, Module
          The patch therefore refactors the top "skin" of every Core-to-Core
          pass, but does not change their functionality.
      
      2.  It adds a completely new facility to GHC: Core "annotations".
          The idea is that you can say
             {#- ANN foo (Just "Hello") #-}
          which adds the annotation (Just "Hello") to the top level function
          foo.  These annotations can be looked up in any Core-to-Core pass,
          and are persisted into interface files.  (Hence a Core-to-Core pass
          can also query the annotations of imported things.)  Furthermore,
          a Core-to-Core pass can add new annotations (eg strictness info)
          of its own, which can be queried by importing modules.
      
      The design of the annotation system is somewhat in flux.  It's
      designed to work with the (upcoming) dynamic plug-ins mechanism,
      but is meanwhile independently useful.
      
      Do not merge to 6.10!  
      9bcd95ba
  14. 21 Oct, 2008 1 commit
  15. 20 Sep, 2008 1 commit
  16. 21 Oct, 2008 2 commits
    • chak@cse.unsw.edu.au.'s avatar
      FIX #2693 · fbbd2bfa
      chak@cse.unsw.edu.au. authored
      - As long as the first reduceContext in tcSimplifyRestricted potentially
        performs improvement, we need to zonk again before the second reduceContext.
        It would be better to prevent the improvement in the first place, but given
        the current situation zonking is definitely the right thing to do.
      
        MERGE TO 6.10
      fbbd2bfa
    • chak@cse.unsw.edu.au.'s avatar
      FIX #2688 · e47c481d
      chak@cse.unsw.edu.au. authored
      - Change in TcSimplify.reduceContext:
      
           We do *not* go around for new extra_eqs.  Morally, we should,
           but we can't without risking non-termination (see #2688).  By
           not going around, we miss some legal programs mixing FDs and
           TFs, but we never claimed to support such programs in the
           current implementation anyway.
      
        MERGE TO 6.10
      e47c481d
  17. 02 Oct, 2008 2 commits
  18. 01 Oct, 2008 3 commits
  19. 18 Sep, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #1470: improve handling of recursive instances (needed for SYB3) · 5045af31
      simonpj@microsoft.com authored
      This bug has been hanging around for a long time, as you'll see by its
      number. The fix implements a feature that is really needed by SYB3, to
      allow an instance to (rather indirectly) refer to itself.  The trickiness
      comes when solving the superclass constraints.
      
      The whoel issue is explained in Note [Recursive instances and superclases]
      in TcSimplify.
      
      In cracking this one I found I could remove the WantSCs argument to the
      ReduceMe flag, which is a worthwhile simplification.  Good!
      5045af31
  20. 16 Sep, 2008 1 commit
  21. 14 Sep, 2008 2 commits
  22. 13 Sep, 2008 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Type families: completed the new equality solver · e8917205
      chak@cse.unsw.edu.au. authored
      - Implements normalisation of class constraints containing synonym family
        applications or skolems refined by local equalities.
      - Clean up of TcSimplify.reduceContext by using the new equality solver.
      - Removed all the now unused code of the old algorithm.
      - This completes the implementation of the new algorithm, but it is largely
        untested => many regressions.
      e8917205
  23. 11 Aug, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #2494: tcSimplifyRuleLhs · 4016ee2f
      simonpj@microsoft.com authored
      tcSimplifyRuleLhs is a cut-down constraint simplifier, intended for
      use in RULE left-hand-sides.  But it was written before implication
      constraints, and the exmaple of this bug report shows that when higher
      rank types are involved we need to be a bit cleverer.
      
      The whole business of simplifying constraints on rule LHSs is a bit
      of a hack; but for a good reason.  See the comments with tcSimplifyRuleLhs.
      This patch at least cures the crash.
      
      4016ee2f
  24. 31 Jul, 2008 1 commit
  25. 20 Jul, 2008 1 commit
  26. 16 Jun, 2008 1 commit
    • Ian Lynagh's avatar
      More commandline flag improvements · 0f5e104c
      Ian Lynagh authored
      * Allow -ffoo flags to be deprecated
      * Mark some -ffoo flags as deprecated
      * Avoid using deprecated flags in error messages, in the build system, etc
      * Add a flag to en/disable the deprecated flag warning
      0f5e104c
  27. 06 Jun, 2008 1 commit
  28. 05 Jun, 2008 2 commits
  29. 03 Jun, 2008 1 commit
  30. 12 Apr, 2008 1 commit
  31. 07 Apr, 2008 1 commit
  32. 29 Mar, 2008 2 commits