1. 26 Jan, 2017 1 commit
    • Matthew Pickering's avatar
      COMPLETE pragmas for enhanced pattern exhaustiveness checking · 1a3f1eeb
      Matthew Pickering authored
      This patch adds a new pragma so that users can specify `COMPLETE` sets of
      `ConLike`s in order to sate the pattern match checker.
      
      A function which matches on all the patterns in a complete grouping
      will not cause the exhaustiveness checker to emit warnings.
      
      ```
      pattern P :: ()
      pattern P = ()
      
      {-# COMPLETE P #-}
      
      foo P = ()
      ```
      
      This example would previously have caused the checker to warn that
      all cases were not matched even though matching on `P` is sufficient to
      make `foo` covering. With the addition of the pragma, the compiler
      will recognise that matching on `P` alone is enough and not emit
      any warnings.
      
      Reviewers: goldfire, gkaracha, alanz, austin, bgamari
      
      Reviewed By: alanz
      
      Subscribers: lelf, nomeata, gkaracha, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2669
      
      GHC Trac Issues: #8779
      1a3f1eeb
  2. 25 Jan, 2017 4 commits
  3. 24 Jan, 2017 15 commits
  4. 23 Jan, 2017 7 commits
    • niteria's avatar
      Make tickishContains faster · 532c6ade
      niteria authored
      This just reorders some inequality checks to make the common case
      cheaper.
      
      The results are quite dramatic for #11095, but that's probably because
      something else is causing it to do too much work.
      
      Before (full https://phabricator.haskell.org/P136):
      ```
        13,589,495,832 bytes allocated in the heap
      ```
      
      After (full https://phabricator.haskell.org/P137):
      ```
         7,885,575,872 bytes allocated in the heap
      ```
      
      This is with `BuildFlavour = devel2`, so take it with a
      a grain of salt.
      
      For reference, with no `-g` I get:
      ```
      155,703,112 bytes allocated in the heap
      ```
      so we're still quite a way off.
      
      Test Plan:
      harbormaster
      I still have to test locally
      
      Reviewers: austin, bgamari
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D3001
      
      GHC Trac Issues: #11095
      532c6ade
    • Simon Peyton Jones's avatar
      Record evaluated-ness on workers and wrappers · 596dece7
      Simon Peyton Jones authored
      Summary:
      This patch is a refinement of the original commit (which
      was reverted):
      
        commit 6b976eb8
        Date:   Fri Jan 13 08:56:53 2017 +0000
            Record evaluated-ness on workers and wrappers
      
      In Trac #13027, comment:20, I noticed that wrappers created after
      demand analysis weren't recording the evaluated-ness of strict
      constructor arguments.  In the ticket that led to a (debatable)
      Lint error but in general the more we know about evaluated-ness
      the better we can optimise.
      
      This commit adds that info
        * both in the worker (on args)
        * and in the wrapper (on CPR result patterns).
      See Note [Record evaluated-ness in worker/wrapper] in WwLib
      
      On the way I defined Id.setCaseBndrEvald, and used it to shorten
      the code in a few other places
      
      Then I added test T13077a to test the CPR aspect of this patch,
      but I found that Lint failed!
      
      Reason: simpleOptExpr was discarding evaluated-ness info on
      lambda binders because zapFragileIdInfo was discarding an
      Unfolding of (OtherCon _).  But actually that's a robust
      unfolding; there is no need to discard it. To fix this:
      
      * zapFragileIdInfo only zaps fragile unfoldings
      
      * Replace isClosedUnfolding with isFragileUnfolding (the latter
        is just the negation of the former, but the nomenclature is
        more consistent).  Better documentation too
             Note [Fragile unfoldings]
      
      * And Simplify.simplLamBndr can now look at isFragileUnfolding
        to decide whether to use the longer route of simplUnfolding.
      
      For some reason perf/compiler/T9233 improves in compile-time
      allocation by 10%.  Hooray
      
      Nofib: essentially no change:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
            cacheprof          +0.0%     -0.3%     +0.9%     +0.4%     +0.0%
      --------------------------------------------------------------------------------
                  Min          +0.0%     -0.3%     -2.4%     -2.4%     +0.0%
                  Max          +0.0%     +0.0%     +9.8%    +11.4%     +2.4%
       Geometric Mean          +0.0%     -0.0%     +1.1%     +1.0%     +0.0%
      596dece7
    • Ryan Scott's avatar
      Don't quantify implicit type variables when quoting type signatures in TH · 729a5e45
      Ryan Scott authored
      Summary:
      A bug was introduced in GHC 8.0 in which Template Haskell-quoted type
      signatures would quantify _all_ their type variables, even the implicit ones.
      This would cause splices like this:
      
      ```
      $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a
            idProxy x = x
         |])
      ```
      
      To splice back in something that was slightly different:
      
      ```
      idProxy :: forall k proxy (a :: k). proxy a -> proxy a
      idProxy x = x
      ```
      
      Notice that the kind variable `k` is now explicitly quantified! What's worse,
      this now requires the `TypeInType` extension to be enabled.
      
      This changes the behavior of Template Haskell quoting to never explicitly
      quantify type variables which are implicitly quantified in the source.
      
      There are some other places where this behavior pops up too, including
      class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports,
      and pattern synonynms (#13018), so I fixed those too.
      
      Fixes #13018 and #13123.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj, goldfire
      
      Subscribers: simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2974
      
      GHC Trac Issues: #13018, #13123
      729a5e45
    • niteria's avatar
      Make checkFamInstConsistency faster · 18ceb148
      niteria authored
      We've noticed that `checkFamInstConsistency` takes 6% of
      overall build time on our codebase.
      I've poked around for a bit and most of type family
      instances are `Rep` from `Generics`. I think those are
      unavoidable, so I don't think we can have less of them.
      
      I also looked at the code and noticed a simple algorithmic
      improvement can be made. The algorithm is pretty simple:
      we take all the family instances from one module (`M1`)
      and test it against another module (`M2`).
      The cost of that is dominated by the size of `M1`, because
      for each instance in `M1` we look it up in the type family
      env from `M2`, and lookup is cheap.
      If `M1` is bigger than `M2`, that's suboptimal, so after
      my change we always iterate through the smaller set.
      
      This drives down the cost of `checkFamInstConsistency`
      to 2%.
      
      Test Plan: harbormaster
      
      Reviewers: simonmar, simonpj, goldfire, rwbarton, bgamari, ezyang, austin
      
      Reviewed By: rwbarton, ezyang
      
      Subscribers: ezyang, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2833
      18ceb148
    • Gabor Greif's avatar
      Typos and grammar in manual/comments · 80560e69
      Gabor Greif authored
      80560e69
    • Simon Peyton Jones's avatar
      Apply the right substitution in ty-fam improvement · 2b64e926
      Simon Peyton Jones authored
      Trac #13135 showed that we were failing to apply the
      correct substitution to the un-substituted tyvars during
      type-family improvement using injectivity.  Specifically
      in TcInteractlinjImproveEqns we need to use instFlexiX.
      
      An outright bug, easy to fix.
      
      Slight refactoring along the way.  The quantified tyars of the axiom are
      readily to hand; we don't need to take the free tyvars of the LHS
      2b64e926
    • Simon Peyton Jones's avatar
      Improve pretty-printing of IfaceCoercions · 6850eb64
      Simon Peyton Jones authored
      For some reason, unless you have -fprint-explicit-coercions, when
      printing an explicit coercion we were then going to special trouble to
      suppress the unique of a hole (which only happens during debugging
      anyway).  This is bizarre.
      
      So I deleted three lines of code -- hooray.
      6850eb64
  5. 22 Jan, 2017 7 commits
  6. 21 Jan, 2017 1 commit
    • niteria's avatar
      Always use -Xlinker for -rpath · f9ccad23
      niteria authored
      Currently we use `-Wl` which takes a list of
      comma-separated options. Unfortunately that
      breaks when you use it with `-rpath` and
      a path that has commas in them.
      Buck, the build system, produces paths with
      commas in them.
      
      `-Xlinker` doesn't have this disadvantage
      and as far as I can tell is supported by
      both `gcc` and `clang`. Anecdotally `nvcc`
      supports `-Xlinker`, but not `-Wl`.
      
      Test Plan: ./validate, harbourmaster
      
      Reviewers: nomeata, simonmar, austin, bgamari, hvr
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2971
      f9ccad23
  7. 20 Jan, 2017 5 commits