GitLab

This tests various properties expected to hold for
quotRem, divMod, div, mod, quot, and rem.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

  * CmmRewriteAddignments module was replaced by CmmSink a long
    time ago. That module is now available at
    https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Hoopl/Examples
    wiki page.

  * removeDeadAssignments function was not used and it was also
    moved to the above page.

  * I also nuked some commented out debugging code that was not
    used for 1,5 year.

It turns out that one of the cases in the optimization pass was
a special case of another. I remove that specialization since it
does not have impact on compilation time, and the resulting Cmm
is identical.

Fixes #8585

When emmiting label of a self-recursive tail call (ie. when
performing loopification optimization) we emit the loop header
label after a stack check but before the heap check. The reason is
that tail-recursive functions use constant amount of stack space
so we don't need to repeat the check in every loop. But they can
grow the heap so heap check must be repeated in every call.
See Note [Self-recursive tail calls] and [Self-recursive loop header].

so that one can build a source distribution without downloading the
windows tarballs.

as there is no testsuite/.git any more.

This update pulls in the fix for #8266

(recommended add-on reading for those interested in OSX linker peculiarities:
https://github.com/haskell/cabal/issues/1660#issuecomment-33701508 )
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

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

We want it to show up in GHC.Exts, so we need to put the documentation
in GHC.Types, where the datatype Coercible is defined.

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

This is for building performance-optimized cross compilers (e.g. the iOS
target.)
Signed-off-by: Austin Seipp <austin@well-typed.com>

As Luke Iannini reported, the Clang iOS cross compiler apparently
doesn't support __thread for some bizarre reason, so unfortunately they
too must fall back to pthread_{get,set}specific.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

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 4ade9627Signed-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.