1. 27 Oct, 2010 1 commit
  2. 15 Sep, 2010 1 commit
  3. 04 May, 2010 1 commit
  4. 06 Jan, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Improve the handling of default methods · 77166b17
      simonpj@microsoft.com authored
      See the long Note [INLINE and default methods].  
      
      This patch changes a couple of data types, with a knock-on effect on
      the format of interface files.  A lot of files get touched, but is a
      relatively minor change.  The main tiresome bit is the extra plumbing
      to communicate default methods between the type checker and the
      desugarer.
      77166b17
  5. 18 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Move loop-breaker info from original function to worker in work/wrap · ed0ad23b
      simonpj@microsoft.com authored
      When doing a w/w split, if the original function is a loop breaker
      then the worker (not the wrapper) becomes one instead.
      
      This isn't very important, because loop breaker information is
      recalculated afresh by the occurrence analyser, but it seems more
      kosher.  And Lint was bleating piteously about things with InlineRules
      that were loop breakers.
      ed0ad23b
  6. 16 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Adjust Activations for specialise and work/wrap, and better simplify in InlineRules · 76dfa394
      simonpj@microsoft.com 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.
      76dfa394
  7. 02 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      More work on the simplifier's inlining strategies · c86161c5
      simonpj@microsoft.com authored
      This patch collects a small raft of related changes
      
      * Arrange that during 
           (a) rule matching and 
           (b) uses of exprIsConApp_maybe
        we "look through" unfoldings only if they are active
        in the phase. Doing this for (a) required a bit of 
        extra plumbing in the rule matching code, but I think
        it's worth it.
      
        One wrinkle is that even if inlining is off (in the 'gentle'
        phase of simplification) during rule matching we want to
        "look through" things with inlinings.  
         See SimplUtils.activeUnfInRule.
      
        This fixes a long-standing bug, where things that were
        supposed to be (say) NOINLINE, could still be poked into
        via exprIsConApp_maybe. 
      
      * In the above cases, also check for (non-rule) loop breakers; 
        we never look through these.  This fixes a bug that could make
        the simplifier diverge (and did for Roman).  
        Test = simplCore/should_compile/dfun-loop
      
      * Try harder not to choose a DFun as a loop breaker. This is 
        just a small adjustment in the OccurAnal scoring function
      
      * In the scoring function in OccurAnal, look at the InlineRule
        unfolding (if there is one) not the actual RHS, beause the
        former is what'll be inlined.  
      
      * Make the application of any function to dictionary arguments
        CONLIKE.  Thus (f d1 d2) is CONLIKE.  
        Encapsulated in CoreUtils.isExpandableApp
        Reason: see Note [Expandable overloadings] in CoreUtils
      
      * Make case expressions seem slightly smaller in CoreUnfold.
        This reverses an unexpected consequences of charging for
        alternatives.
      
      Refactorings
      ~~~~~~~~~~~~
      * Signficantly refactor the data type for Unfolding (again). 
        The result is much nicer.  
      
      * Add type synonym BasicTypes.CompilerPhase = Int
        and use it
      
      Many of the files touched by this patch are simply knock-on
      consequences of these two refactorings.
      c86161c5
  8. 26 Nov, 2009 1 commit
  9. 19 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Remove the (very) old strictness analyser · 2662dbc5
      simonpj@microsoft.com authored
      I finally got tired of the #ifdef OLD_STRICTNESS stuff.  I had been
      keeping it around in the hope of doing old-to-new comparisions, but
      have failed to do so for many years, so I don't think it's going to
      happen.  This patch deletes the clutter.
      2662dbc5
  10. 29 Oct, 2009 1 commit
    • simonpj@microsoft.com's avatar
      The Big INLINE Patch: totally reorganise way that INLINE pragmas work · 72462499
      simonpj@microsoft.com authored
      This patch has been a long time in gestation and has, as a
      result, accumulated some extra bits and bobs that are only
      loosely related.  I separated the bits that are easy to split
      off, but the rest comes as one big patch, I'm afraid.
      
      Note that:
       * It comes together with a patch to the 'base' library
       * Interface file formats change slightly, so you need to
         recompile all libraries
      
      The patch is mainly giant tidy-up, driven in part by the
      particular stresses of the Data Parallel Haskell project. I don't
      expect a big performance win for random programs.  Still, here are the
      nofib results, relative to the state of affairs without the patch
      
              Program           Size    Allocs   Runtime   Elapsed
      --------------------------------------------------------------------------------
                  Min         -12.7%    -14.5%    -17.5%    -17.8%
                  Max          +4.7%    +10.9%     +9.1%     +8.4%
       Geometric Mean          +0.9%     -0.1%     -5.6%     -7.3%
      
      The +10.9% allocation outlier is rewrite, which happens to have a
      very delicate optimisation opportunity involving an interaction
      of CSE and inlining (see nofib/Simon-nofib-notes). The fact that
      the 'before' case found the optimisation is somewhat accidental.
      Runtimes seem to go down, but I never kno wwhether to really trust
      this number.  Binary sizes wobble a bit, but nothing drastic.
      
      
      The Main Ideas are as follows.
      
      InlineRules
      ~~~~~~~~~~~
      When you say 
            {-# INLINE f #-}
            f x = <rhs>
      you intend that calls (f e) are replaced by <rhs>[e/x] So we
      should capture (\x.<rhs>) in the Unfolding of 'f', and never meddle
      with it.  Meanwhile, we can optimise <rhs> to our heart's content,
      leaving the original unfolding intact in Unfolding of 'f'.
      
      So the representation of an Unfolding has changed quite a bit
      (see CoreSyn).  An INLINE pragma gives rise to an InlineRule 
      unfolding.  
      
      Moreover, it's only used when 'f' is applied to the
      specified number of arguments; that is, the number of argument on 
      the LHS of the '=' sign in the original source definition. 
      For example, (.) is now defined in the libraries like this
         {-# INLINE (.) #-}
         (.) f g = \x -> f (g x)
      so that it'll inline when applied to two arguments. If 'x' appeared
      on the left, thus
         (.) f g x = f (g x)
      it'd only inline when applied to three arguments.  This slightly-experimental
      change was requested by Roman, but it seems to make sense.
      
      Other associated changes
      
      * Moving the deck chairs in DsBinds, which processes the INLINE pragmas
      
      * In the old system an INLINE pragma made the RHS look like
         (Note InlineMe <rhs>)
        The Note switched off optimisation in <rhs>.  But it was quite
        fragile in corner cases. The new system is more robust, I believe.
        In any case, the InlineMe note has disappeared 
      
      * The workerInfo of an Id has also been combined into its Unfolding,
        so it's no longer a separate field of the IdInfo.
      
      * Many changes in CoreUnfold, esp in callSiteInline, which is the critical
        function that decides which function to inline.  Lots of comments added!
      
      * exprIsConApp_maybe has moved to CoreUnfold, since it's so strongly
        associated with "does this expression unfold to a constructor application".
        It can now do some limited beta reduction too, which Roman found 
        was an important.
      
      Instance declarations
      ~~~~~~~~~~~~~~~~~~~~~
      It's always been tricky to get the dfuns generated from instance
      declarations to work out well.  This is particularly important in 
      the Data Parallel Haskell project, and I'm now on my fourth attempt,
      more or less.
      
      There is a detailed description in TcInstDcls, particularly in
      Note [How instance declarations are translated].   Roughly speaking
      we now generate a top-level helper function for every method definition
      in an instance declaration, so that the dfun takes a particularly
      stylised form:
        dfun a d1 d2 = MkD (op1 a d1 d2) (op2 a d1 d2) ...etc...
      
      In fact, it's *so* stylised that we never need to unfold a dfun.
      Instead ClassOps have a special rewrite rule that allows us to
      short-cut dictionary selection.  Suppose dfun :: Ord a -> Ord [a]
                                                  d :: Ord a
      Then   
          compare (dfun a d)  -->   compare_list a d 
      in one rewrite, without first inlining the 'compare' selector
      and the body of the dfun.
      
      To support this
      a) ClassOps have a BuiltInRule (see MkId.dictSelRule)
      b) DFuns have a special form of unfolding (CoreSyn.DFunUnfolding)
         which is exploited in CoreUnfold.exprIsConApp_maybe
      
      Implmenting all this required a root-and-branch rework of TcInstDcls
      and bits of TcClassDcl.
      
      
      Default methods
      ~~~~~~~~~~~~~~~
      If you give an INLINE pragma to a default method, it should be just
      as if you'd written out that code in each instance declaration, including
      the INLINE pragma.  I think that it now *is* so.  As a result, library
      code can be simpler; less duplication.
      
      
      The CONLIKE pragma
      ~~~~~~~~~~~~~~~~~~
      In the DPH project, Roman found cases where he had
      
         p n k = let x = replicate n k
                 in ...(f x)...(g x)....
      
         {-# RULE f (replicate x) = f_rep x #-}
      
      Normally the RULE would not fire, because doing so involves 
      (in effect) duplicating the redex (replicate n k).  A new
      experimental modifier to the INLINE pragma, {-# INLINE CONLIKE
      replicate #-}, allows you to tell GHC to be prepared to duplicate
      a call of this function if it allows a RULE to fire.
      
      See Note [CONLIKE pragma] in BasicTypes
      
      
      Join points
      ~~~~~~~~~~~
      See Note [Case binders and join points] in Simplify
      
      
      Other refactoring
      ~~~~~~~~~~~~~~~~~
      * I moved endPass from CoreLint to CoreMonad, with associated jigglings
      
      * Better pretty-printing of Core
      
      * The top-level RULES (ones that are not rules for locally-defined things)
        are now substituted on every simplifier iteration.  I'm not sure how
        we got away without doing this before.  This entails a bit more plumbing
        in SimplCore.
      
      * The necessary stuff to serialise and deserialise the new
        info across interface files.
      
      * Something about bottoming floats in SetLevels
            Note [Bottoming floats]
      
      * substUnfolding has moved from SimplEnv to CoreSubs, where it belongs
      
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed
      --------------------------------------------------------------------------------
                 anna          +2.4%     -0.5%      0.16      0.17
                 ansi          +2.6%     -0.1%      0.00      0.00
                 atom          -3.8%     -0.0%     -1.0%     -2.5%
               awards          +3.0%     +0.7%      0.00      0.00
               banner          +3.3%     -0.0%      0.00      0.00
           bernouilli          +2.7%     +0.0%     -4.6%     -6.9%
                boyer          +2.6%     +0.0%      0.06      0.07
               boyer2          +4.4%     +0.2%      0.01      0.01
                 bspt          +3.2%     +9.6%      0.02      0.02
            cacheprof          +1.4%     -1.0%    -12.2%    -13.6%
             calendar          +2.7%     -1.7%      0.00      0.00
             cichelli          +3.7%     -0.0%      0.13      0.14
              circsim          +3.3%     +0.0%     -2.3%     -9.9%
             clausify          +2.7%     +0.0%      0.05      0.06
        comp_lab_zift          +2.6%     -0.3%     -7.2%     -7.9%
             compress          +3.3%     +0.0%     -8.5%     -9.6%
            compress2          +3.6%     +0.0%    -15.1%    -17.8%
          constraints          +2.7%     -0.6%    -10.0%    -10.7%
         cryptarithm1          +4.5%     +0.0%     -4.7%     -5.7%
         cryptarithm2          +4.3%    -14.5%      0.02      0.02
                  cse          +4.4%     -0.0%      0.00      0.00
                eliza          +2.8%     -0.1%      0.00      0.00
                event          +2.6%     -0.0%     -4.9%     -4.4%
               exp3_8          +2.8%     +0.0%     -4.5%     -9.5%
               expert          +2.7%     +0.3%      0.00      0.00
                  fem          -2.0%     +0.6%      0.04      0.04
                  fft          -6.0%     +1.8%      0.05      0.06
                 fft2          -4.8%     +2.7%      0.13      0.14
             fibheaps          +2.6%     -0.6%      0.05      0.05
                 fish          +4.1%     +0.0%      0.03      0.04
                fluid          -2.1%     -0.2%      0.01      0.01
               fulsom          -4.8%     +9.2%     +9.1%     +8.4%
               gamteb          -7.1%     -1.3%      0.10      0.11
                  gcd          +2.7%     +0.0%      0.05      0.05
          gen_regexps          +3.9%     -0.0%      0.00      0.00
               genfft          +2.7%     -0.1%      0.05      0.06
                   gg          -2.7%     -0.1%      0.02      0.02
                 grep          +3.2%     -0.0%      0.00      0.00
               hidden          -0.5%     +0.0%    -11.9%    -13.3%
                  hpg          -3.0%     -1.8%     +0.0%     -2.4%
                  ida          +2.6%     -1.2%      0.17     -9.0%
                infer          +1.7%     -0.8%      0.08      0.09
              integer          +2.5%     -0.0%     -2.6%     -2.2%
            integrate          -5.0%     +0.0%     -1.3%     -2.9%
              knights          +4.3%     -1.5%      0.01      0.01
                 lcss          +2.5%     -0.1%     -7.5%     -9.4%
                 life          +4.2%     +0.0%     -3.1%     -3.3%
                 lift          +2.4%     -3.2%      0.00      0.00
            listcompr          +4.0%     -1.6%      0.16      0.17
             listcopy          +4.0%     -1.4%      0.17      0.18
             maillist          +4.1%     +0.1%      0.09      0.14
               mandel          +2.9%     +0.0%      0.11      0.12
              mandel2          +4.7%     +0.0%      0.01      0.01
              minimax          +3.8%     -0.0%      0.00      0.00
              mkhprog          +3.2%     -4.2%      0.00      0.00
           multiplier          +2.5%     -0.4%     +0.7%     -1.3%
             nucleic2          -9.3%     +0.0%      0.10      0.10
                 para          +2.9%     +0.1%     -0.7%     -1.2%
            paraffins         -10.4%     +0.0%      0.20     -1.9%
               parser          +3.1%     -0.0%      0.05      0.05
              parstof          +1.9%     -0.0%      0.00      0.01
                  pic          -2.8%     -0.8%      0.01      0.02
                power          +2.1%     +0.1%     -8.5%     -9.0%
               pretty         -12.7%     +0.1%      0.00      0.00
               primes          +2.8%     +0.0%      0.11      0.11
            primetest          +2.5%     -0.0%     -2.1%     -3.1%
               prolog          +3.2%     -7.2%      0.00      0.00
               puzzle          +4.1%     +0.0%     -3.5%     -8.0%
               queens          +2.8%     +0.0%      0.03      0.03
              reptile          +2.2%     -2.2%      0.02      0.02
              rewrite          +3.1%    +10.9%      0.03      0.03
                 rfib          -5.2%     +0.2%      0.03      0.03
                  rsa          +2.6%     +0.0%      0.05      0.06
                  scc          +4.6%     +0.4%      0.00      0.00
                sched          +2.7%     +0.1%      0.03      0.03
                  scs          -2.6%     -0.9%     -9.6%    -11.6%
               simple          -4.0%     +0.4%    -14.6%    -14.9%
                solid          -5.6%     -0.6%     -9.3%    -14.3%
              sorting          +3.8%     +0.0%      0.00      0.00
               sphere          -3.6%     +8.5%      0.15      0.16
               symalg          -1.3%     +0.2%      0.03      0.03
                  tak          +2.7%     +0.0%      0.02      0.02
            transform          +2.0%     -2.9%     -8.0%     -8.8%
             treejoin          +3.1%     +0.0%    -17.5%    -17.8%
            typecheck          +2.9%     -0.3%     -4.6%     -6.6%
              veritas          +3.9%     -0.3%      0.00      0.00
                 wang          -6.2%     +0.0%      0.18     -9.8%
            wave4main         -10.3%     +2.6%     -2.1%     -2.3%
         wheel-sieve1          +2.7%     -0.0%     +0.3%     -0.6%
         wheel-sieve2          +2.7%     +0.0%     -3.7%     -7.5%
                 x2n1          -4.1%     +0.1%      0.03      0.04
      --------------------------------------------------------------------------------
                  Min         -12.7%    -14.5%    -17.5%    -17.8%
                  Max          +4.7%    +10.9%     +9.1%     +8.4%
       Geometric Mean          +0.9%     -0.1%     -5.6%     -7.3%
      72462499
  11. 07 Jul, 2009 1 commit
  12. 29 May, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3259: expose 'lazy' only after generating interface files · 0abcc755
      simonpj@microsoft.com authored
      This patch fixes an insidious and long-standing bug in the way that
      parallelism is handled in GHC.  See Note [lazyId magic] in MkId.
      
      Here's the diagnosis, copied from the Trac ticket.  par is defined 
      in GHC.Conc thus:
      
          {-# INLINE par  #-}
          par :: a -> b -> b
          par  x y = case (par# x) of { _ -> lazy y }
      
          -- The reason for the strange "lazy" call is that it fools the
          -- compiler into thinking that pseq and par are non-strict in
          -- their second argument (even if it inlines pseq/par at the call
          -- site).  If it thinks par is strict in "y", then it often
          -- evaluates "y" before "x", which is totally wrong.
      
      The function lazy is the identity function, but it is inlined only
      after strictness analysis, and (via some magic) pretends to be
      lazy. Hence par pretends to be lazy too.
      
      The trouble is that both par and lazy are inlined into your definition
      of parallelise, so that the unfolding for parallelise (exposed in
      Parallelise.hi) does not use lazy at all. Then when compiling Main,
      parallelise is in turn inlined (before strictness analysis), and so
      the strictness analyser sees too much.
      
      This was all sloppy thinking on my part. Inlining lazy after
      strictness analysis works fine for the current module, but not for
      importing modules.
      
      The fix implemented by this patch is to inline 'lazy' in CorePrep,
      not in WorkWrap. That way interface files never see the inlined version.
      
      The downside is that a little less optimisation may happen on programs
      that use 'lazy'.  And you'll only see this in the results -ddump-prep
      not in -ddump-simpl.  So KEEP AN EYE OUT (Simon and Satnam especially).
      Still, it should work properly now.  Certainly fixes #3259.
      
      0abcc755
  13. 03 Apr, 2009 1 commit
    • 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
  14. 18 Mar, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Add the notion of "constructor-like" Ids for rule-matching · 4bc25e8c
      simonpj@microsoft.com authored
      This patch adds an optional CONLIKE modifier to INLINE/NOINLINE pragmas, 
         {-# NOINLINE CONLIKE [1] f #-}
      The effect is to allow applications of 'f' to be expanded in a potential
      rule match.  Example
        {-# RULE "r/f" forall v. r (f v) = f (v+1) #-}
      
      Consider the term
           let x = f v in ..x...x...(r x)...
      Normally the (r x) would not match the rule, because GHC would be scared
      about duplicating the redex (f v). However the CONLIKE modifier says to
      treat 'f' like a constructor in this situation, and "look through" the
      unfolding for x.  So (r x) fires, yielding (f (v+1)).
      
      The main changes are:
        - Syntax
      
        - The inlinePragInfo field of an IdInfo has a RuleMatchInfo
          component, which records whether or not the Id is CONLIKE.
          Of course, this needs to be serialised in interface files too.
      
        - The occurrence analyser (OccAnal) and simplifier (Simplify) treat
          CONLIKE thing like constructors, by ANF-ing them
      
        - New function coreUtils.exprIsExpandable is like exprIsCheap, but
          additionally spots applications of CONLIKE functions
      
        - A CoreUnfolding has a field that caches exprIsExpandable
      
        - The rule matcher consults this field.  See 
          Note [Expanding variables] in Rules.lhs.
      
      On the way I fixed a lurking variable bug in the way variables are
      expanded.  See Note [Do not expand locally-bound variables] in
      Rule.lhs.  I also did a bit of reformatting and refactoring in
      Rules.lhs, so the module has more lines changed than are really
      different.
      4bc25e8c
  15. 13 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Rewrite CorePrep and improve eta expansion · 62eeda5a
      simonpj@microsoft.com authored
      This patch does two main things
      
      a) Rewrite most of CorePrep to be much easier to understand (I hope!).
         The invariants established by CorePrep are now written out, and
         the code is more perspicuous.  It is surpringly hard to get right,
         and the old code had become quite incomprehensible.
      
      b) Rewrite the eta-expander so that it does a bit of simplifying
         on-the-fly, and thereby guarantees to maintain the CorePrep
         invariants.  This make it much easier to use from CorePrep, and
         is a generally good thing anyway.
      
      A couple of pieces of re-structuring:
      
      *  I moved the eta-expander and arity analysis stuff into a new
         module coreSyn/CoreArity.
      
         Max will find that the type CoreArity.EtaInfo looks strangely 
         familiar.
      
      *  I moved a bunch of comments from Simplify to OccurAnal; that's
         why it looks as though there's a lot of lines changed in those
         modules.
      
      On the way I fixed various things
      
        - Function arguments are eta expanded
             f (map g)  ===>  let s = \x. map g x in f s
      
        - Trac #2368
      
      The result is a modest performance gain, I think mainly due
      to the first of these changes:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed
      --------------------------------------------------------------------------------
                  Min          -1.0%    -17.4%    -19.1%    -46.4%
                  Max          +0.3%     +0.5%     +5.4%    +53.8%
       Geometric Mean          -0.1%     -0.3%     -7.0%    -10.2%
      
      
      62eeda5a
  16. 02 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Make record selectors into ordinary functions · 9ffadf21
      simonpj@microsoft.com authored
      This biggish patch addresses Trac #2670.  The main effect is to make
      record selectors into ordinary functions, whose unfoldings appear in
      interface files, in contrast to their previous existence as magic
      "implicit Ids".  This means that the usual machinery of optimisation,
      analysis, and inlining applies to them, which was failing before when
      the selector was somewhat complicated.  (Which it can be when
      strictness annotations, unboxing annotations, and GADTs are involved.)
      
      The change involves the following points
      
      * Changes in Var.lhs to the representation of Var.  Now a LocalId can
        have an IdDetails as well as a GlobalId.  In particular, the
        information that an Id is a record selector is kept in the
        IdDetails.  While compiling the current module, the record selector
        *must* be a LocalId, so that it participates properly in compilation
        (free variables etc).
      
        This led me to change the (hidden) representation of Var, so that there
        is now only one constructor for Id, not two.
      
      * The IdDetails is persisted into interface files, so that an
        importing module can see which Ids are records selectors.
      
      * In TcTyClDecls, we generate the record-selector bindings in renamed,
        but not typechecked form.  In this way, we can get the typechecker
        to add all the types and so on, which is jolly helpful especially
        when GADTs or type families are involved.  Just like derived
        instance declarations.
      
        This is the big new chunk of 180 lines of code (much of which is
        commentary).  A call to the same function, mkAuxBinds, is needed in
        TcInstDcls for associated types.
      
      * The typechecker therefore has to pin the correct IdDetails on to 
        the record selector, when it typechecks it.  There was a neat way
        to do this, by adding a new sort of signature to HsBinds.Sig, namely
        IdSig.  This contains an Id (with the correct Name, Type, and IdDetails);
        the type checker uses it as the binder for the final binding.  This
        worked out rather easily.
      
      * Record selectors are no longer "implicit ids", which entails changes to
           IfaceSyn.ifaceDeclSubBndrs
           HscTypes.implicitTyThings
           TidyPgm.getImplicitBinds
        (These three functions must agree.)
      
      * MkId.mkRecordSelectorId is deleted entirely, some 300+ lines (incl
        comments) of very error prone code.  Happy days.
      
      * A TyCon no longer contains the list of record selectors: 
        algTcSelIds is gone
      
      The renamer is unaffected, including the way that import and export of
      record selectors is handled.
      
      Other small things
      
      * IfaceSyn.ifaceDeclSubBndrs had a fragile test for whether a data
        constructor had a wrapper.  I've replaced that with an explicit flag
        in the interface file. More robust I hope.
      
      * I renamed isIdVar to isId, which touched a few otherwise-unrelated files.
      
      9ffadf21
  17. 29 Dec, 2008 1 commit
  18. 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
  19. 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
  20. 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
  21. 07 Aug, 2008 1 commit
  22. 25 Jan, 2008 1 commit
  23. 24 Jan, 2008 1 commit
    • Ian Lynagh's avatar
      Fix the build · 6c7b41cc
      Ian Lynagh authored
      Work around various problems caused by some of the monadification patches
      not being applied.
      6c7b41cc
  24. 17 Jan, 2008 1 commit
  25. 21 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Do not worker/wrapper INLINE things, even if they are in a recursive group · 5ed66aa2
      simonpj@microsoft.com authored
      This patch stops the worker/wrapper transform working on an INLINE thing,
      even if it's in a recursive group.  It might not be the loop breaker.  Indeed
      a recursive group might have no loop breaker, if the only recursion is 
      through rules.
      
      Again, this change was provoked by one of Roman's NDP libraries.
      Specifically the Rec { splitD, splitJoinD } group in 
      	Data.Array.Parallel.Unlifted.Distributed.Arrays
      
      Simon
      5ed66aa2
  26. 07 Dec, 2007 1 commit
  27. 04 Sep, 2007 1 commit
  28. 03 Sep, 2007 1 commit
  29. 01 Sep, 2007 1 commit
  30. 07 Jun, 2007 1 commit
  31. 02 Feb, 2007 1 commit
  32. 12 Oct, 2006 1 commit
  33. 04 Aug, 2006 1 commit
  34. 22 May, 2006 1 commit
  35. 17 May, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Retain InlinePragInfo on wrappers · c55bcbde
      simonpj@microsoft.com authored
      For some reason, when doing the worker/wrapper split, we transferred the
      InlinePragInfo from the original function, but expunging it from the wrapper.
      This meant, for example, that a NOINLINE function would have its wrapper
      inlined, which isn't sensible.
      
      For a change, fixing a bug involves only deleting code!
      c55bcbde
  36. 08 May, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Remove NOINLINE strictness hack · 302265d5
      simonpj@microsoft.com authored
      The stricteness analyser used to have a HACK which ensured that NOINLNE things
      were not strictness-analysed.  The reason was unsafePerformIO. Left to itself,
      the strictness analyser would discover this strictness for unsafePerformIO:
      	unsafePerformIO:  C(U(AV))
      But then consider this sub-expression
      	unsafePerformIO (\s -> let r = f x in 
      			       case writeIORef v r s of (# s1, _ #) ->
      			       (# s1, r #)
      The strictness analyser will now find that r is sure to be eval'd,
      and may then hoist it out.  This makes tests/lib/should_run/memo002
      deadlock.
      
      Solving this by making all NOINLINE things have no strictness info is overkill.
      In particular, it's overkill for runST, which is perfectly respectable.
      Consider
      	f x = runST (return x)
      This should be strict in x.
      
      So the new plan is to define unsafePerformIO using the 'lazy' combinator:
      
      	unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r)
      
      Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is 
      magically NON-STRICT, and is inlined after strictness analysis.  So
      unsafePerformIO will look non-strict, and that's what we want.
      
      Now we don't need the hack in the strictness analyser.
      302265d5
  37. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  38. 10 Aug, 2005 1 commit
  39. 18 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-18 13:37:27 by simonmar] · d1c1b7d0
      simonmar authored
      Flags cleanup.
      
      Basically the purpose of this commit is to move more of the compiler's
      global state into DynFlags, which is moving in the direction we need
      to go for the GHC API which can have multiple active sessions
      supported by a single GHC instance.
      
      Before:
      
      $ grep 'global_var' */*hs | wc -l
           78
      
      After:
      
      $ grep 'global_var' */*hs | wc -l
           27
      
      Well, it's an improvement.  Most of what's left won't really affect
      our ability to host multiple sessions.
      
      Lots of static flags have become dynamic flags (yay!).  Notably lots
      of flags that we used to think of as "driver" flags, like -I and -L,
      are now dynamic.  The most notable static flags left behind are the
      "way" flags, eg. -prof.  It would be nice to fix this, but it isn't
      urgent.
      
      On the way, lots of cleanup has happened.  Everything related to
      static and dynamic flags lives in StaticFlags and DynFlags
      respectively, and they share a common command-line parser library in
      CmdLineParser.  The flags related to modes (--makde, --interactive
      etc.) are now private to the front end: in fact private to Main
      itself, for now.
      d1c1b7d0
  40. 22 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-22 12:06:13 by simonpj] · d7c402a3
      simonpj authored
      ----------------------------------------
           New Core invariant: keep case alternatives in sorted order
      	----------------------------------------
      
      We now keep the alternatives of a Case in the Core language in sorted
      order.  Sorted, that is,
      	by constructor tag	for DataAlt
      	by literal		for LitAlt
      
      The main reason is that it makes matching and equality testing more robust.
      But in fact some lines of code vanished from SimplUtils.mkAlts.
      
      
      WARNING: no change to interface file formats, but you'll need to recompile
      your libraries so that they generate interface files that respect the
      invariant.
      d7c402a3