1. 10 Feb, 2010 3 commits
    • simonpj@microsoft.com's avatar
      Improve error dump in TcEnv · d259dd70
      simonpj@microsoft.com authored
      d259dd70
    • simonpj@microsoft.com's avatar
      Keep track of explicit kinding in HsTyVarBndr; plus fix Trac #3845 · 836b1e90
      simonpj@microsoft.com authored
      To print HsTypes correctly we should remember whether the Kind on
      a HsTyVarBndr came from type inference, or was put there by the
      user.  See Note [Printing KindedTyVars] in HsTypes.  So instead of
      changing a UserTyVar to a KindedTyVar during kind checking, we
      simply add a PostTcKind to the UserTyVar.
      
      The change was provoked by Trac #3830, although other changes
      mean that #3830 gets a diferent and better error message now.
      So this patch is simply doing the Right Thing for the future.
      
      This patch also fixes Trac #3845, which was caused by a *type splice*
      not remembering the free *term variables* mentioned in it.  Result
      was that we build a 'let' when it should have been 'letrec'.
      Hence a new FreeVars field in HsSpliceTy.
      
      While I was at it, I got rid of HsSpliceTyOut and use a PostTcKind
      on HsSpliceTy instead, just like on the UserTyVar.
      836b1e90
    • simonpj@microsoft.com's avatar
  2. 08 Feb, 2010 1 commit
  3. 10 Feb, 2010 4 commits
    • simonpj@microsoft.com's avatar
      Stop fruitless ANF-ing · 9a977e72
      simonpj@microsoft.com authored
      The simplifier is taking more iterations than it should, because we
      were fruitlessly ANF-ing a top-level declaration of form
      
         x = Ptr "foo"#
      
      to get
       
         x = let v = "foo"# in Ptr v
      
      and then inlining v again.  This patch makes Simplify.makeTrivial 
      top-level aware, so that it doesn't ANF if it's going to be undone.
      9a977e72
    • simonpj@microsoft.com's avatar
      Comments only · 90686adf
      simonpj@microsoft.com authored
      90686adf
    • simonpj@microsoft.com's avatar
      Simplify syntax for quasi-quotation · 26f164e5
      simonpj@microsoft.com authored
      After some discussion we decided to make a quasi-quote look like
      
         [pads| ...blah... |]
      
      rather than
      
         [$pads| ...blah... |]
      
      as before. The new syntax is quieter, although it does not signal
      quite as clearly that there is a splice going on.
      26f164e5
    • simonpj@microsoft.com's avatar
      Several TH/quasiquote changes · 6f8ff0bb
      simonpj@microsoft.com authored
      a) Added quasi-quote forms for
            declarations
            types
         e.g.   f :: [$qq| ... |]
      
      b) Allow Template Haskell pattern quotes (but not splices)
         e.g.  f x = [p| Int -> $x |]
      
      c) Improve pretty-printing for HsPat to remove superfluous
         parens.  (This isn't TH related really, but it affects
         some of the same code.)
      
      
      A consequence of (a) is that when gathering and grouping declarations
      in RnSource.findSplice, we must expand quasiquotes as we do so.
      Otherwise it's all fairly straightforward.  I did a little bit of
      refactoring in TcSplice.
      
      User-manual changes still to come.
      6f8ff0bb
  4. 09 Feb, 2010 2 commits
  5. 08 Feb, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3850 · dafabe65
      simonpj@microsoft.com authored
      This patch simply avoids a needless difference in behaviour from 
      6.10, and one that happens to affect HList. See Note [Stupid theta].
      dafabe65
  6. 05 Feb, 2010 1 commit
  7. 04 Feb, 2010 1 commit
    • Simon Marlow's avatar
      Implement SSE2 floating-point support in the x86 native code generator (#594) · 335b9f36
      Simon Marlow authored
      The new flag -msse2 enables code generation for SSE2 on x86.  It
      results in substantially faster floating-point performance; the main
      reason for doing this was that our x87 code generation is appallingly
      bad, and since we plan to drop -fvia-C soon, we need a way to generate
      half-decent floating-point code.
      
      The catch is that SSE2 is only available on CPUs that support it (P4+,
      AMD K8+).  We'll have to think hard about whether we should enable it
      by default for the libraries we ship.  In the meantime, at least
      -msse2 should be an acceptable replacement for "-fvia-C
      -optc-ffast-math -fexcess-precision".
      
      SSE2 also has the advantage of performing all operations at the
      correct precision, so floating-point results are consistent with other
      platforms.
      
      I also tweaked the x87 code generation a bit while I was here, now
      it's slighlty less bad than before.
      335b9f36
  8. 03 Feb, 2010 6 commits
  9. 02 Feb, 2010 1 commit
  10. 30 Jan, 2010 1 commit
  11. 01 Feb, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3831: blowup in SpecConstr · 13c66820
      simonpj@microsoft.com authored
      It turned out that there were two bugs.  First, we were getting an
      exponential number of specialisations when we had a deep nest of
      join points.  See Note [Avoiding exponential blowup]. I fixed this
      by dividing sc_count (in ScEnv) by the number of specialisations
      when recursing.  Crude but effective.
      
      Second, when making specialisations I was looking at the result of
      applying specExpr to the RHS of the function, whereas I should have
      been looking at the original RHS.  See Note [Specialise original
      body].
      
      
      There's a tantalising missed opportunity here, though.  In this
      example (recorded as a test simplCore/should_compile/T3831), each join
      point has *exactly one* call pattern, so we should really just
      specialise for that alone, in which case there's zero code-blow-up.
      In particular, we don't need the *original* RHS at all.  I need to think
      more about how to exploit this.
      
      But the blowup is now limited, so compiling terminfo with -O2 works again.
      13c66820
  12. 29 Jan, 2010 1 commit
  13. 28 Jan, 2010 1 commit
    • Simon Marlow's avatar
      tweak the totally-bogus arbitrary stack-squeezing heuristic to fix #2797 · 990171bf
      Simon Marlow authored
      In #2797, a program that ran in constant stack space when compiled
      needed linear stack space when interpreted.  It turned out to be
      nothing more than stack-squeezing not happening.  We have a heuristic
      to avoid stack-squeezing when it would be too expensive (shuffling a
      large amount of memory to save a few words), but in some cases even
      expensive stack-squeezing is necessary to avoid linear stack usage.
      One day we should implement stack chunks, which would make this less
      expensive.
      990171bf
  14. 27 Jan, 2010 9 commits
  15. 26 Jan, 2010 4 commits
  16. 22 Jan, 2010 3 commits
    • Simon Marlow's avatar
      When acquiring a spinlock, yieldThread() every 1000 spins (#3553, #3758) · 65ac2f4c
      Simon Marlow authored
      This helps when the thread holding the lock has been descheduled,
      which is the main cause of the "last-core slowdown" problem.  With
      this patch, I get much better results with -N8 on an 8-core box,
      although some benchmarks are still worse than with 7 cores.
      
      I also added a yieldThread() into the any_work() loop of the parallel
      GC when it has no work to do. Oddly, this seems to improve performance
      on the parallel GC benchmarks even when all the cores are busy.
      Perhaps it is due to reducing contention on the memory bus.
      65ac2f4c
    • Simon Marlow's avatar
      'store' should be static (#3835) · f1d99ae0
      Simon Marlow authored
      f1d99ae0
    • Simon Marlow's avatar
      Add some missing getStablePtr()s for CAFs that the RTS refers to · 849ce0c7
      Simon Marlow authored
      A recent patch ("Refactor CoreArity a bit") changed the arity of
      GHC.Conc.runSparks such that it became a CAF, and the RTS was not
      explicitly retaining it, which led to a crash when the CAF got GC'd.
      While fixing this I found a couple of other closures that the RTS
      refers to which weren't getting the correct CAF treatment.
      849ce0c7