GitLab

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.

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.

At least until we switch to --lazy being the default

This patch simply avoids a needless difference in behaviour from 
6.10, and one that happens to affect HList. See Note [Stupid theta].

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.

This flag seems buggy on GCC 4.1.2, which is the only GCC version we 
have that can bootstrap the SPARC build. We end up with lots of supurious
warnings of the form "cast increases required alignment of target type".
Some legitimate warnings can be fixed by adding an intermediate cast to
(void*), but we get others in rts/sm/GCUtils.c concerning the gct var
that look innocuous to me. We could enable this again once we deprecate
support for registerised builds on this arch.

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.

This was a lot easier than I imagined.

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.

After a bound thread had completed, its TSO remains in the heap until
it has been GC'd, although the associated Task is returned to the
caller where it is freed and possibly re-used.  

The bug was that GC was following the pointer to the Task and updating
the TSO field, meanwhile the Task had already been recycled (it was
being used by exitScheduler()). Confusion ensued, leading to a very
occasional deadlock at shutdown, but in principle it could result in
other crashes too.

The fix is to remove the link between the TSO and the Task when the
TSO has completed and the call to schedule() has returned; see
comments in Schedule.c.

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.

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.

In 6.14.1 we'll switch these primops to return the exact byte size,
but for 6.12.2 we need to fix the docs.