1. 22 Jul, 2015 3 commits
    • Simon Marlow's avatar
      Eliminate zero_static_objects_list() · b949c96b
      Simon Marlow authored
      Summary:
      In a workload with a large amount of code, zero_static_objects_list()
      takes a significant amount of time, and furthermore it is in the
      single-threaded part of the GC.
      
      This patch uses a slightly fiddly scheme for marking objects on the
      static object lists, using a flag in the low 2 bits that flips between
      two states to indicate whether an object has been visited during this
      GC or not.  We also have to take into account objects that have not
      been visited yet, which might appear at any time due to runtime linking.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, ezyang, rwbarton
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1076
      b949c96b
    • thomie's avatar
      1b76997d
    • thomie's avatar
      Revert "Trac #4945 is working again" · 50b9a7a3
      thomie authored
      This reverts commit 5d98b682.
      50b9a7a3
  2. 21 Jul, 2015 28 commits
  3. 20 Jul, 2015 9 commits
    • thomie's avatar
      Update submodule hpc with fix for #10529 · b4ef8b8b
      thomie authored
      b4ef8b8b
    • thomie's avatar
      Testsuite: simplify T8089 (#8089) · d0cf8f1a
      thomie authored
      The previous implementation wasn't working for the `ghci` test way,
      causing a fulltest failure.
      
      Differential Revision: https://phabricator.haskell.org/D1075
      d0cf8f1a
    • thomie's avatar
    • thomie's avatar
      Testsuite: fix concprog002 (AMP) · d71d9a9e
      thomie authored
      Requires random to be installed.
      d71d9a9e
    • Ben Gamari's avatar
      Fix primops documentation syntax · 96de8098
      Ben Gamari authored
      96de8098
    • Luite Stegeman's avatar
      Do not treat prim and javascript imports as C imports in TH and QQ · 4cd008b6
      Luite Stegeman authored
      Reviewers: austin, hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1070
      
      GHC Trac Issues: #10638
      4cd008b6
    • Ben Gamari's avatar
      primops: Add haddocks to BCO primops · c526e095
      Ben Gamari authored
      Test Plan: none
      
      Reviewers: simonmar, austin, hvr
      
      Subscribers: hvr, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1082
      
      GHC Trac Issues: #10640
      c526e095
    • thomasw's avatar
      Support wild cards in TH splices · 49373ffe
      thomasw authored
      - Declaration splices: partial type signatures are fully supported in TH
        declaration splices.
      
        For example, the wild cards in the example below will unify with `Eq
      a`
        and `a -> a -> Bool`, as expected:
      
      ```
      [d| foo :: _ => _
          foo x y = x == y |]
      ```
      
      - Expression splices: anonymous and named wild cards are supported in
        expression signatures, but extra-constraints wild cards aren't. Just
        as is the case for regular expression signatures.
      
      ```
      [e | Just True :: _a _ |]
      ```
      
      - Typed expression splices: the same wildcards as in (untyped)
        expression splices are supported.
      
      - Pattern splices: TH doesn't support type signatures in pattern
        splices, consequently, partial type signatures aren't supported
        either.
      
      - Type splices: partial type signatures are only partially supported in
        type splices, specifically: only anonymous wild cards are allowed.
      
        So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or
        `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as
        the named wild card is treated as a type variable).
      
        Normally, named wild cards are collected before renaming a (partial)
        type signature. However, TH type splices are run during renaming, i.e.
        after the initial traversal, leading to out of scope errors for named
        wild cards. We can't just extend the initial traversal to collect the
        named wild cards in TH type splices, as we'd need to expand them,
        which is supposed to happen only once, during renaming.
      
        Similarly, the extra-constraints wild card is handled right before
        renaming too, and is therefore also not supported in a TH type splice.
        Another reason not to support extra-constraints wild cards in TH type
        splices is that a single signature can contain many TH type splices,
        whereas it mustn't contain more than one extra-constraints wild card.
        Enforcing would this be hard the way things are currently organised.
      
        Anonymous wild cards pose no problem, because they start without names
        and are given names during renaming. These names are collected right
        after renaming. The names generated for anonymous wild cards in TH
        type splices will thus be collected as well.
      
        With a more invasive refactoring of the renaming, partial type
        signatures could be fully supported in TH type splices. As only
        anonymous wild cards have been requested so far, these small changes
        satisfying this request will do for now. Also don't forget that a TH
        declaration splices support all kinds of wild cards.
      
      - Extra-constraints wild cards were silently ignored in expression and
        pattern signatures, appropriate error messages are now generated.
      
      Test Plan: run new tests
      
      Reviewers: austin, goldfire, adamgundry, bgamari
      
      Reviewed By: goldfire, adamgundry, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1048
      
      GHC Trac Issues: #10094, #10548
      49373ffe
    • Michal Terepeta's avatar
      LlvmCodeGen: add support for MO_U_Mul2 CallishMachOp · 82ffc80d
      Michal Terepeta authored
      This adds support MO_U_Mul2 to the LLVM backend by simply using 'mul'
      instruction but operating at twice the bit width (e.g., for 64 bit
      words we will generate mul that operates on 128 bits and then extract
      the two 64 bit values for the result of the CallishMachOp).
      
      Test Plan: validate
      
      Reviewers: rwbarton, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1068
      
      GHC Trac Issues: #9430
      82ffc80d