1. 10 Feb, 2010 1 commit
  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 5 commits