1. 25 Jan, 2017 4 commits
  2. 24 Jan, 2017 15 commits
  3. 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
  4. 22 Jan, 2017 7 commits
  5. 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
  6. 20 Jan, 2017 6 commits
    • Yuras's avatar
      Warn on missing home modules · 15b9a85e
      Yuras authored
      Introduce a warning, -Wmissing-home-modules, to warn about home modules,
      not listed in command line.
      
      It is usefull for cabal when user fails to list a module in
      `exposed-modules` and `other-modules`.
      
      Test Plan: make TEST=MissingMod
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2977
      
      GHC Trac Issues: #13129
      15b9a85e
    • dobenour's avatar
      Clean up some shell code and M4 quoting · c43011da
      dobenour authored
      
      Test Plan: GHC CI
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2993
      c43011da
    • rwbarton's avatar
      testsuite: Don't fail if "target has RTS linker" field is missing · b626a001
      rwbarton authored
      Test Plan: harbormaster
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2991
      b626a001
    • rwbarton's avatar
      Add a failing test for #13099 · b4761317
      rwbarton authored
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2990
      
      GHC Trac Issues: #13099
      b4761317
    • Phil de Joux's avatar
      Show explicit quantifiers in conflicting definitions error · 33140f41
      Phil de Joux authored
      This fixes #12441, where definitions in a Haskell module and its boot
      file which differed only in their quantifiers produced a confusing error
      message. Here we teach GHC to always show quantifiers for these errors.
      
      Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2734
      
      GHC Trac Issues: #12441
      33140f41
    • takano-akio's avatar
      Allow top-level string literals in Core (#8472) · d49b2bb2
      takano-akio authored
      This commits relaxes the invariants of the Core syntax so that a
      top-level variable can be bound to a primitive string literal of type
      Addr#.
      
      This commit:
      
      * Relaxes the invatiants of the Core, and allows top-level bindings whose
        type is Addr# as long as their RHS is either a primitive string literal or
        another variable.
      
      * Allows the simplifier and the full-laziness transformer to float out
        primitive string literals to the top leve.
      
      * Introduces the new StgGenTopBinding type to accomodate top-level Addr#
        bindings.
      
      * Introduces a new type of labels in the object code, with the suffix "_bytes",
        for exported top-level Addr# bindings.
      
      * Makes some built-in rules more robust. This was necessary to keep them
        functional after the above changes.
      
      This is a continuation of D2554.
      
      Rebasing notes:
      This had two slightly suspicious performance regressions:
      
      * T12425: bytes allocated regressed by roughly 5%
      * T4029: bytes allocated regressed by a bit over 1%
      * T13035: bytes allocated regressed by a bit over 5%
      
      These deserve additional investigation.
      
      Rebased by: bgamari.
      
      Test Plan: ./validate --slow
      
      Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari
      
      Reviewed By: trofi, simonpj, bgamari
      
      Subscribers: trofi, simonpj, gridaphobe, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2605
      
      GHC Trac Issues: #8472
      d49b2bb2