1. 26 Feb, 2017 1 commit
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored
      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.
      3415bcaa
  2. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      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
      5d38fb69
  3. 10 Jun, 2016 1 commit
    • Simon Marlow's avatar
      NUMA support · 9e5ea67e
      Simon Marlow authored
      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
      9e5ea67e
  4. 16 May, 2016 1 commit
    • Peter Trommler's avatar
      PPC: Implement SMP primitives using gcc built-ins · 563a4857
      Peter Trommler authored
      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
      563a4857
  5. 25 Feb, 2016 1 commit
    • Peter Trommler's avatar
      testsuite: mark tests broken on powerpc64 · feb19eae
      Peter Trommler authored
      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
      feb19eae
  6. 11 Feb, 2013 1 commit
  7. 20 Jul, 2011 1 commit
  8. 01 Apr, 2010 1 commit
  9. 28 Jun, 2008 1 commit
  10. 11 Sep, 2007 1 commit
  11. 18 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-18 16:31:10 by simonmar] · ff6b4956
      simonmar authored
      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.
      ff6b4956
  12. 13 Sep, 2005 1 commit