1. 15 Feb, 2010 5 commits
  2. 14 Feb, 2010 1 commit
  3. 11 Feb, 2010 1 commit
  4. 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
  5. 08 Feb, 2010 1 commit
  6. 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
  7. 09 Feb, 2010 2 commits
  8. 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
  9. 05 Feb, 2010 1 commit
  10. 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
  11. 03 Feb, 2010 6 commits
  12. 02 Feb, 2010 1 commit
  13. 30 Jan, 2010 1 commit
  14. 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
  15. 29 Jan, 2010 1 commit
  16. 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
  17. 27 Jan, 2010 9 commits