1. 04 Jan, 2012 1 commit
    • Simon Marlow's avatar
      dsCImport (CLabel): drop foralls when checking for FunPtr · 0545b550
      Simon Marlow authored
      We were mislabelling some foreign imports as IsData rather than
      IsFunction, because the type was forall a. FunPtr (... a ...).
      
      Eventually this gave rise to these obscure error when compiling
      unregisterised:
      
      libraries/base/Foreign/Marshal/Alloc.hc:473:0:
           warning: built-in function ‘free’ declared as non-function
      
      libraries/base/Foreign/Marshal/Alloc.hc:1004:0:
           error: ‘free’ redeclared as different kind of symbol
      0545b550
  2. 06 Dec, 2011 1 commit
    • Simon Marlow's avatar
      Make forkProcess work with +RTS -N · 8b75acd3
      Simon Marlow authored
      Consider this experimental for the time being.  There are a lot of
      things that could go wrong, but I've verified that at least it works
      on the test cases we have.
      
      I also did some API cleanups while I was here.  Previously we had:
      
      Capability * rts_eval (Capability *cap, HaskellObj p, /*out*/HaskellObj *ret);
      
      but this API is particularly error-prone: if you forget to discard the
      Capability * you passed in and use the return value instead, then
      you're in for subtle bugs with +RTS -N later on.  So I changed all
      these functions to this form:
      
      void rts_eval (/* inout */ Capability **cap,
                     /* in    */ HaskellObj p,
                     /* out */   HaskellObj *ret)
      
      It's much harder to use this version incorrectly, because you have to
      pass the Capability in by reference.
      8b75acd3
  3. 28 Nov, 2011 1 commit
    • Ian Lynagh's avatar
      Implement a capi calling convention; fixes #2979 · 36f8cabe
      Ian Lynagh authored
      In GHC, this provides an easy way to call a C function via a C wrapper.
      This is important when the function is really defined by CPP.
      
      Requires the new CApiFFI extension.
      
      Not documented yet, as it's still an experimental feature at this stage.
      36f8cabe
  4. 26 Nov, 2011 2 commits
  5. 01 Oct, 2011 1 commit
  6. 27 Sep, 2011 1 commit
  7. 03 Aug, 2011 1 commit
  8. 01 Jul, 2011 1 commit
  9. 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
      fdf86568
  10. 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
      92267aa2
  11. 15 Sep, 2010 1 commit
  12. 29 Mar, 2010 1 commit
  13. 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
  14. 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
  15. 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
  16. 28 Jul, 2009 1 commit
  17. 27 Jul, 2009 1 commit
  18. 26 Jun, 2009 1 commit
  19. 09 Jun, 2009 1 commit
    • Duncan Coutts's avatar
      Desugaring for "foreign import prim" · 5b7e2a87
      Duncan Coutts authored
      Unlike normal foreign imports which desugar into a separate worker and
      wrapper, we use just a single wrapper decleration. The representation
      in Core of the call is currently as a foreign call. This means the
      args are all treated as fully strict. This is ok at the moment because
      we restrict the types for foreign import prim to be of unboxed types,
      however in future we may want to make prim imports be the normal cmm
      calling convention for Haskell functions, in which case we would not
      be able to assume all args are strict. At that point it may make more
      sense to represent cmm/prim calls distinct from foreign calls, and
      more like the we the existing PrimOp calls are handled.
      5b7e2a87
  20. 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
  21. 06 Feb, 2009 1 commit
    • Ian Lynagh's avatar
      When generating C, don't pretend functions are data · 497302c4
      Ian Lynagh authored
      We used to generated things like:
          extern StgWordArray (newCAF) __attribute__((aligned (8)));
          ((void (*)(void *))(W_)&newCAF)((void *)R1.w);
      (which is to say, pretend that newCAF is some data, then cast it to a
      function and call it).
      This goes wrong on at least IA64, where:
          A function pointer on the ia64 does not point to the first byte of
          code. Intsead, it points to a structure that describes the function.
          The first quadword in the structure is the address of the first byte
          of code
      so we end up dereferencing function pointers one time too many, and
      segfaulting.
      497302c4
  22. 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
  23. 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
  24. 14 Aug, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Merging in the new codegen branch · 176fa33f
      dias@eecs.harvard.edu authored
      This merge does not turn on the new codegen (which only compiles
      a select few programs at this point),
      but it does introduce some changes to the old code generator.
      
      The high bits:
      1. The Rep Swamp patch is finally here.
         The highlight is that the representation of types at the
         machine level has changed.
         Consequently, this patch contains updates across several back ends.
      2. The new Stg -> Cmm path is here, although it appears to have a
         fair number of bugs lurking.
      3. Many improvements along the CmmCPSZ path, including:
         o stack layout
         o some code for infotables, half of which is right and half wrong
         o proc-point splitting
      176fa33f
  25. 31 Jul, 2008 1 commit
  26. 14 Jun, 2008 2 commits
  27. 14 May, 2008 1 commit
    • Simon Marlow's avatar
      FIX #2276: foreign import stdcall "&foo" doesn't work · bca74f3e
      Simon Marlow authored
      This turned out not to be too hard, just a matter of figuring out the
      correct argument list size by peeking inside FunPtr's type argument,
      and in the C backend we have to emit an appropriate prototype for the label.
      bca74f3e
  28. 12 Apr, 2008 1 commit
  29. 02 Apr, 2008 1 commit
    • Simon Marlow's avatar
      Do not #include external header files when compiling via C · c245355e
      Simon Marlow authored
      This has several advantages:
      
       - -fvia-C is consistent with -fasm with respect to FFI declarations:
         both bind to the ABI, not the API.
      
       - foreign calls can now be inlined freely across module boundaries, since
         a header file is not required when compiling the call.
      
       - bootstrapping via C will be more reliable, because this difference
         in behavour between the two backends has been removed.
      
      There is one disadvantage:
      
       - we get no checking by the C compiler that the FFI declaration
         is correct.
      
      So now, the c-includes field in a .cabal file is always ignored by
      GHC, as are header files specified in an FFI declaration.  This was
      previously the case only for -fasm compilations, now it is also the
      case for -fvia-C too.
      c245355e
  30. 16 Feb, 2008 1 commit
  31. 04 Jan, 2008 1 commit
  32. 17 Jan, 2008 1 commit
  33. 03 Jan, 2008 1 commit
    • Simon Marlow's avatar
      Optionally use libffi to implement 'foreign import "wrapper"' (#793) · 5123ae93
      Simon Marlow authored
      To enable this, set UseLibFFI=YES in mk/build.mk.  
      
      The main advantage here is that this reduces the porting effort for
      new platforms: libffi works on more architectures than our current
      adjustor code, and it is probably more heavily tested.  We could
      potentially replace our existing code, but since it is probably faster
      than libffi (just a guess, I'll measure later) and is already working,
      it doesn't seem worthwhile.
      
      Right now, you must have libffi installed on your system.  I used the
      one supplied by Debian/Ubuntu.
      5123ae93
  34. 04 Sep, 2007 1 commit
  35. 03 Sep, 2007 1 commit
  36. 01 Sep, 2007 1 commit
  37. 26 Aug, 2007 1 commit
    • Simon Marlow's avatar
      Refactoring only: remove [Id] field from ForeignStubs · 663b3914
      Simon Marlow authored
      We used to pass the list of top-level foreign exported bindings to the
      code generator so that it could create StablePtrs for them in the
      stginit code.  Now we don't use stginit unless profiling, and the
      StablePtrs are generated by C functions marked with
      attribute((constructor)).  This patch removes various bits associated
      with the old way of doing things, which were previously left in place
      in case we wanted to switch back, I presume.  Also I refactored
      dsForeigns to clean it up a bit.
      663b3914
  38. 09 Aug, 2007 1 commit