Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

This basically cleans a lot of GCTDecl up - I found it quite hard to
read and a bit confusing. The changes are mostly cosmetic: better
delineation between the alternative cases and light touchups, and tries
to make every branch as consistent as possible.

However, this patch does have one significant effect: it will ensure
that any LLVM-based compilers will use __thread if they support it.
Before, they would simply always use pthread_getspecific and
pthread_setspecific, which are almost surely even *more* inefficient.

The details are a bit too long and boring to go into here; see #7602.
After talking with Simon, we decided to play it safe - __thread can at
least be optimized by future clang releases even further on OS X if they
choose, and it's safer until we can investigate the pthread
implementation further on Mavericks.

For Linux, the story isn't so bleak if you use Clang (for whatever
reason) - Linux directly writes to `%fs` for __thread slots (while OS X
will perform a load followed by an indirect call.) So it should still be
fairly competitive, speed-wise.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

I forgot to push these from my win32 machine. A lot of them actually
look like a result of Herbert doing his GMP work, which might slightly
affect allocations on platforms like Windows (where we always use
in-tree GMP - but presumably Windows allocations could fluxuate slightly
due to minute details in the GMP implementation, too.)

Signed-off-by: Austin Seipp <austin@well-typed.com>

Fallout from 4ade9627

Signed-off-by: Austin Seipp <austin@well-typed.com>

The binutils linker on ARM emits unnecessary R_ARM_COPY relocations
which breaks tables-next-to-code in dynamically linked modules. This
check should be more selective but there is currently no released
version where this bug is fixed.  See
https://sourceware.org/bugzilla/show_bug.cgi?id=16177 and
https://ghc.haskell.org/trac/ghc/ticket/4210#comment:29

 for details.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

This fixes #7134

Signed-off-by: Austin Seipp <austin@well-typed.com>

This change seems worth mentioning

I did some refactoring of the demand analyser, because I was smelling
some minor code smell. Most of my changes I had to undo, though,
adding notes and testcases on why the existing code was correct after
all.

Especially the semantics of the DmdResult is confusing, as it differs in
a DmdType and a StrictSig.

I got to imrpove the readability of the code for lubDmdType, though.

Also, dmdAnalRhs was a bit fishy in how it removed the demand on
further arguments of the body, but used the DmdResult. This would be
wrong if a body would return a demand type of "<L>m" (which currently
does not happen).  This is now treated better in removeDmdTyArgs.

catching mistakes that I had during my refactoring, and which I do not
want to do again.

Signed-off-by: Austin Seipp <austin@well-typed.com>

My build settings were wrong last time.

Signed-off-by: Austin Seipp <austin@well-typed.com>

This reverts commit c5088e29.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Some of these are actually worse than I thought upon inspection, but
after a little digging I haven't found exactly what has caused them.
Some were certainly bitrotted, but others seem updated more recently, so
something has slipped.

I'll be filing a ticket about these.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

In particular, spell out the current dynamic situation, clean up the
FIXMEs and xrefs, and don't forget to mention InterruptibleFFI.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Rather hilarious (and my fault.)

Signed-off-by: Austin Seipp <austin@well-typed.com>

A few appear to have bitrotted a little. There are others we are
actually doing better on, but that will come in the next commit.

Signed-off-by: Austin Seipp <austin@well-typed.com>

When using TemplateHaskell and -prof, we *do not* want -dynamic-too, because
we're going to *expect* that you compiled the vanilla/dyn way already,
and are compiling profiling the second time (i.e. so GHCi can just load
the normal, non-profiled object files.)

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
allowing y ou to assign names to a pattern and abstract over it.

The rundown is this:

  * Named patterns are introduced by the new 'pattern' keyword, and can
    be either *unidirectional* or *bidirectional*. A unidirectional
    pattern is, in the simplest sense, simply an 'alias' for a pattern,
    where the LHS may mention variables to occur in the RHS. A
    bidirectional pattern synonym occurs when a pattern may also be used
    in expression context.

  * Unidirectional patterns are declared like thus:

        pattern P x <- x:_

    The synonym 'P' may only occur in a pattern context:

        foo :: [Int] -> Maybe Int
        foo (P x) = Just x
        foo _     = Nothing

  * Bidirectional patterns are declared like thus:

        pattern P x y = [x, y]

    Here, P may not only occur as a pattern, but also as an expression
    when given values for 'x' and 'y', i.e.

        bar :: Int -> [Int]
        bar x = P x 10

  * Patterns can't yet have their own type signatures; signatures are inferred.

  * Pattern synonyms may not be recursive, c.f. type synonyms.

  * Pattern synonyms are also exported/imported using the 'pattern'
    keyword in an import/export decl, i.e.

        module Foo (pattern Bar) where ...

    Note that pattern synonyms share the namespace of constructors, so
    this disambiguation is required as a there may also be a 'Bar'
    type in scope as well as the 'Bar' pattern.

  * The semantics of a pattern synonym differ slightly from a typical
    pattern: when using a synonym, the pattern itself is matched,
    followed by all the arguments. This means that the strictness
    differs slightly:

        pattern P x y <- [x, y]

        f (P True True) = True
        f _             = False

        g [True, True] = True
        g _            = False

    In the example, while `g (False:undefined)` evaluates to False,
    `f (False:undefined)` results in undefined as both `x` and `y`
    arguments are matched to `True`.

For more information, see the wiki:

    https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
    https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation



Reviewed-by: Simon Peyton Jones <simonpj@microsoft.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

(artificial test cases are so nice: 90.7% improvement!)