GitLab

The script I used is included as testsuite/driver/kill_extra_files.py,
though at this point it is for mostly historical interest.

Some of the tests in libraries/hpc relied on extra_files.py, so this
commit includes an update to that submodule.

One test in libraries/process also relies on extra_files.py, but we
cannot update that submodule so easily, so for now we special-case it
in the test driver.

The `clean_cmd` and `extra_clean` setup functions don't do anything.
Remove them from .T files.

Created using https://github.com/thomie/refactor-ghc-testsuite. This
diff is a test for the .T-file parser/processor/pretty-printer in that
repository.

    find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;

Tests containing inline comments or multiline strings are not modified.

Preparation for #12223.

Test Plan: Harbormaster

Reviewers: austin, hvr, simonmar, mpickering, bgamari

Reviewed By: mpickering

Subscribers: mpickering

Differential Revision: https://phabricator.haskell.org/D3000

GHC Trac Issues: #12223

Summary:
The aim here is to reduce the number of remote memory accesses on
systems with a NUMA memory architecture, typically multi-socket servers.

Linux provides a NUMA API for doing two things:
* Allocating memory local to a particular node
* Binding a thread to a particular node

When given the +RTS --numa flag, the runtime will
* Determine the number of NUMA nodes (N) by querying the OS
* Assign capabilities to nodes, so cap C is on node C%N
* Bind worker threads on a capability to the correct node
* Keep a separate free lists in the block layer for each node
* Allocate the nursery for a capability from node-local memory
* Allocate blocks in the GC from node-local memory

For example, using nofib/parallel/queens on a 24-core 2-socket machine:

```
$ ./Main 15 +RTS -N24 -s -A64m
  Total   time  173.960s  (  7.467s elapsed)

$ ./Main 15 +RTS -N24 -s -A64m --numa
  Total   time  150.836s  (  6.423s elapsed)
```

The biggest win here is expected to be allocating from node-local
memory, so that means programs using a large -A value (as here).

According to perf, on this program the number of remote memory accesses
were reduced by more than 50% by using `--numa`.

Test Plan:
* validate
* There's a new flag --debug-numa=<n> that pretends to do NUMA without
  actually making the OS calls, which is useful for testing the code
  on non-NUMA systems.
* TODO: I need to add some unit tests

Reviewers: erikd, austin, rwbarton, ezyang, bgamari, hvr, niteria

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2199

The SMP primitives were missing appropriate memory barriers
(sync, isync instructions) on all PowerPCs.

Use the built-ins _sync_* provided by gcc and clang. This
reduces code size significantly.

Remove broken mark for concprog001 on powerpc64. The referenced
ticket number (11259) was wrong.

Test Plan: validate on powerpc and ARM

Reviewers: erikd, austin, simonmar, bgamari, hvr

Reviewed By: bgamari, hvr

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2225

GHC Trac Issues: #12070

The following tests fail on powerpc64 and have a ticket.
Mark those tests as expect_broken.

Here are the details:
The PowerPC native code generator does not support DWARF debug
information. This is tracked in ticket #11261. Mark the respective
tests broken on powerpc64.

testsuite: mark print022 broken on powerpc64
Ticket #11262 tracks difference in stdout for print022.

testsuite: mark recomp015 broken on powerpc64
testsuite: mark recomp011 broken on powerpc64
This is tracked as ticket #11323 and #11260.

testsuite: mark linker tests broken on powerpc64
Ticket #11259 tracks tests failing because there is no RTS
linker on powerpc64.

Test Plan: validate

Reviewers: erikd, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1928

GHC Trac Issues: #11259, #11260, #11261, #11262, #11323

It seems to be scheduling sensitive, and sometimes diverges when given
only one core.

This makes the testsuite more resilient when using threads

Add a fast version of the testsuite

The idea is to have a way to run as much of the testsuite as possible
in a short time, so that we'll run it more often (such as just before
checking in a change, for example).  'make fast' tries for good
coverage without using too many cycles.  Currently it takes about 4
minutes on a fast machine with an optimised GHC build; I think this
might still be a little on the slow side.

When you say 'make fast' in testsuite/tests/ghc-regress, we run each
test only one way, and all of the long-running tests are omitted.
Also, to get the runtime down further, I arbitrarily omitted many of
the should_run tests (because these tend to take a lot longer than
should_compile or should_fail tests).  I tried to keep a
representative few in each category.

add test for bug #1285326