1. 15 Sep, 2008 1 commit
  2. 14 Sep, 2008 2 commits
  3. 10 Sep, 2008 2 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #2581: inlining of record selectors · 112ad197
      simonpj@microsoft.com authored
      Bryan discovered that a non-trivial record selector (non-trivial in 
      the sense that it has to reconstruct the result value because of
      UNPACK directives) weren't being inlined.  The reason was that the
      unfolding generated by MkId.mRecordSelId was never being optimised
      *at all*, and hence looked big, and hence wasn't inlined.
      
      (The out-of-line version *is* put into the code of the module
      and *is* optimised, which made this bug pretty puzzling.  But the
      unfolding inside the record-selector-Id itself, which is a GlobalId
      and hence does not get its inlining updated like LocalIds, was
      big and fat.)
      
      Solution: I wrote a very simple optimiser, CoreUnfold.simplOptExpr,
      which does enough optimisation to solve this particular problem.
      It's short, simple, and will be useful in other contexts.
      112ad197
    • simonpj@microsoft.com's avatar
      Comments only · cb579c2b
      simonpj@microsoft.com authored
      cb579c2b
  4. 09 Sep, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Important performance wibble to callSiteInline (the n_vals_wanted > 0 thing) · e71d6d1f
      simonpj@microsoft.com authored
      See Note [Inlining in ArgCtxt].  This very small change gives quite a
      big performance win. Just showing the bigger ones:
      
              Program           Size    Allocs   Runtime
      --------------------------------------------------------------------------------
                 anna          -0.7%     -4.3%      0.15
             cichelli          -0.6%     -6.4%      0.15
               fulsom          -0.4%    -18.5%     -8.1%
                  gcd          -0.6%    -12.0%      0.06
              integer          -0.6%    -16.2%     -8.4%
                power          -0.7%    -19.3%     -4.8%
      --------------------------------------------------------------------------------
                  Min          -0.7%    -19.3%    -15.7%
                  Max          -0.1%     +0.1%     +5.7%
       Geometric Mean          -0.6%     -1.9%     -4.3%
      
      The original change was to improve a case that Roman found (see test
      eyeball/inline1) but that seems to work ok now anyway.
      
      e71d6d1f
  5. 05 Sep, 2008 1 commit
  6. 28 Aug, 2008 1 commit
  7. 07 Aug, 2008 3 commits
  8. 31 Jul, 2008 6 commits
  9. 20 Jul, 2008 1 commit
  10. 08 Jul, 2008 1 commit
  11. 14 Jun, 2008 2 commits
  12. 05 Jun, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add non-recursive let-bindings for types · 1b1190e0
      simonpj@microsoft.com authored
      This patch adds to Core the ability to say
      	let a = Int in <body>
      where 'a' is a type variable.  That is: a type-let.
      See Note [Type let] in CoreSyn.
      
      * The binding is always non-recursive
      * The simplifier immediately eliminates it by substitution 
      
      So in effect a type-let is just a delayed substitution.  This is convenient
      in a couple of places in the desugarer, one existing (see the call to
      CoreTyn.mkTyBind in DsUtils), and one that's in the next upcoming patch.
      
      The first use in the desugarer was previously encoded as
      	(/\a. <body>) Int
      rather that eagerly substituting, but that was horrid because Core Lint
      had do "know" that a=Int inside <body> else it would bleat.  Expressing
      it directly as a 'let' seems much nicer.
      
      1b1190e0
  13. 03 Jun, 2008 1 commit
  14. 28 May, 2008 1 commit
    • Simon Marlow's avatar
      Use MD5 checksums for recompilation checking (fixes #1372, #1959) · 526c3af1
      Simon Marlow authored
      This is a much more robust way to do recompilation checking.  The idea
      is to create a fingerprint of the ABI of an interface, and track
      dependencies by recording the fingerprints of ABIs that a module
      depends on.  If any of those ABIs have changed, then we need to
      recompile.
      
      In bug #1372 we weren't recording dependencies on package modules,
      this patch fixes that by recording fingerprints of package modules
      that we depend on.  Within a package there is still fine-grained
      recompilation avoidance as before.
      
      We currently use MD5 for fingerprints, being a good compromise between
      efficiency and security.  We're not worried about attackers, but we
      are worried about accidental collisions.
      
      All the MD5 sums do make interface files a bit bigger, but compile
      times on the whole are about the same as before.  Recompilation
      avoidance should be a bit more accurate than in 6.8.2 due to fixing
      #1959, especially when using -O.
      526c3af1
  15. 04 May, 2008 2 commits
  16. 12 Apr, 2008 7 commits
  17. 22 Apr, 2008 4 commits
    • simonpj@microsoft.com's avatar
      Simplify SimplCont, plus some other small changes to the Simplifier · 53f99d84
      simonpj@microsoft.com authored
      The main change in this patch is this:
        
        * The Stop constructor of SimplCont no longer contains the OutType
          of the whole continuation.  This is a nice simplification in 
          lots of places where we build a Stop continuation.  For example,
          rebuildCall no longer needs to maintain the type of the function.
      
        * Similarly StrictArg no longer needs an OutType
      
        * The consequential complication is that contResultType (not called
          much) needs to be given the type of the thing in the middle.  No
          big deal.
      
        * Lots of other small knock-on effects
      
      Other changes in here
      
        * simplLazyBind does do the type-abstraction thing if there's
          a lambda inside.  See comments in simplLazyBind
      
        * simplLazyBind reduces simplifier iterations by keeping 
          unfolding information for stuff for which type abstraction is 
          done (see add_poly_bind)
      
      All of this came up when implementing System IF, but seems worth applying
      to the HEAD
      53f99d84
    • simonpj@microsoft.com's avatar
    • chevalier@alum.wellesley.edu's avatar
      Improve External Core syntax for newtypes · e4417dcd
      chevalier@alum.wellesley.edu authored
      I was confused by the newtype eta-contraction trick before.
      Newtype declarations are much less redundant now.
      e4417dcd
    • chevalier@alum.wellesley.edu's avatar
      Naming changes in External Core · b0045fdd
      chevalier@alum.wellesley.edu authored
      Two changes:
      - Top-level bindings in a given module are now printed as a 
        single %rec group. I found that in External Core generated from
        optimized code, nonrec bindings weren't being printed in
        dependency order. Rather than fixing that, I decided to not
        even pretend to preserve dependency order (since there's
        recursion between modules anyway.)
      
      - Internal names are now printed with their uniques attached
        (otherwise, GHC was printing out code with shadowed bindings,
        and this isn't supposed to happen in External Core.)
      b0045fdd
  18. 16 Apr, 2008 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Improve External Core syntax · 2ad4df60
      chevalier@alum.wellesley.edu authored
      Got rid of the silly '^' characters before qualified names (plus:
      reverts to the original syntax; minus: makes the parser a little
      hairier.)
      
      Also, added warning in the typechecker for coercion kind mismatches
      rather than considering that a type error. (see the added comment in
      Check.hs for details.)
      2ad4df60
  19. 14 Apr, 2008 1 commit
  20. 10 Apr, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Ensure that arity is accurate in back end · 3dcb2a66
      simonpj@microsoft.com authored
      See Note [exprArity invariant] in CoreUtils.  In code generated by Happy
      I was seeing this after TidyPgm and CorePrep
      
      	f :: Any
      	f {arity 1} = id `cast` unsafe-co
      
      So f claimed to have arity 1 (because exprArity looked inside), but
      did not have any top-level lambdas (because its type is Any).  
      
      This triggered a slightly-obscure ASSERT failure in CoreToStg
      
      This patch 
      	- makes exprArity trim the arity if the type is not a function
      	- adds a stronger ASSERT in TidyPgm
      
      It's not the only way to solve this problem (see Note [exprArity invariant])
      but it's enough for now. 
      3dcb2a66