1. 12 Dec, 2020 1 commit
  2. 11 Dec, 2020 8 commits
  3. 10 Dec, 2020 3 commits
  4. 09 Dec, 2020 6 commits
    • Andreas Klebinger's avatar
      Bump time submodule. · 54b88eac
      Andreas Klebinger authored
      This should fix #19002.
      54b88eac
    • Andreas Klebinger's avatar
      GHC.Cmm.Opt: Be stricter in results. · 59f2249b
      Andreas Klebinger authored
      Optimization either returns Nothing if nothing is to be done or
      `Just <cmmExpr>` otherwise. There is no point in being lazy in
      `cmmExpr`. We usually inspect this element so the thunk gets forced
      not long after.
      
      We might eliminate it as dead code once in a blue moon but that's
      not a case worth optimizing for.
      
      Overall the impact of this is rather low. As Cmm.Opt doesn't allocate
      much (compared to the rest of GHC) to begin with.
      59f2249b
    • Andreas Klebinger's avatar
      Cmm.Sink: Optimize retaining of assignments, live sets. · aef44d7f
      Andreas Klebinger authored
      Sinking requires us to track live local regs after each
      cmm statement. We used to do this via "Set LocalReg".
      
      However we can replace this with a solution based on IntSet
      which is overall more efficient without losing much. The thing
      we lose is width of the variables, which isn't used by the sinking
      pass anyway.
      
      I also reworked how we keep assignments to regs mentioned in
      skipped assignments. I put the details into
      Note [Keeping assignemnts mentioned in skipped RHSs].
      
      The gist of it is instead of keeping track of it via the use count
      which is a `IntMap Int` we now use the live regs set (IntSet) which
      is quite a bit faster.
      
      I think it also matches the semantics a lot better. The skipped
      (not discarded) assignment does in fact keep the regs on it's rhs
      alive so keeping track of this in the live set seems like the clearer
      solution as well.
      
      Improves allocations for T3294 by yet another 1%.
      aef44d7f
    • Andreas Klebinger's avatar
      Cmm: Make a few types and utility function slightly stricter. · 6e3da800
      Andreas Klebinger authored
      About 0.6% reduction in allocations for the code I was looking at.
      
      Not a huge difference but no need to throw away performance.
      6e3da800
    • Andreas Klebinger's avatar
      CmmSink: Force inlining of foldRegsDefd · 69ae10c3
      Andreas Klebinger authored
      Helps avoid allocating the folding function. Improves
      perf for T3294 by about 1%.
      69ae10c3
    • Andreas Klebinger's avatar
      CodeGen: Make folds User/DefinerOfRegs INLINEABLE. · 51e3bb6d
      Andreas Klebinger authored
      Reduces allocation for the test case I was looking at by about 1.2%.
      Mostly from avoiding allocation of some folding functions which turn
      into let-no-escape bindings which just reuse their environment instead.
      
      We also force inlining in a few key places in CmmSink which helps a bit
      more.
      51e3bb6d
  5. 08 Dec, 2020 2 commits
    • Adam Sandberg Eriksson's avatar
      hadrian: build the _l and _thr_l rts flavours in the develN flavours · 0abe3ddf
      Adam Sandberg Eriksson authored
      The ghc binary requires the eventlog rts since
      fc644b1a
      0abe3ddf
    • Simon Peyton Jones's avatar
      Fix kind inference for data types. Again. · 62ed6957
      Simon Peyton Jones authored
      This patch fixes several aspects of kind inference for data type
      declarations, especially data /instance/ declarations
      
      Specifically
      
      1. In kcConDecls/kcConDecl make it clear that the tc_res_kind argument
         is only used in the H98 case; and in that case there is no result
         kind signature; and hence no need for the disgusting splitPiTys in
         kcConDecls (now thankfully gone).
      
         The GADT case is a bit different to before, and much nicer.
         This is what fixes #18891.
      
         See Note [kcConDecls: kind-checking data type decls]
      
      2. Do not look at the constructor decls of a data/newtype instance
         in tcDataFamInstanceHeader. See GHC.Tc.TyCl.Instance
         Note [Kind inference for data family instances].  This was a
         new realisation that arose when doing (1)
      
         This causes a few knock-on effects in the tests suite, because
         we require more information than before in the instance /header/.
      
         New user-manual material about this in "Kind inference in data type
         declarations" and "Kind inference for data/newtype instance
         declarations".
      
      3. Minor improvement in kcTyClDecl, combining GADT and H98 cases
      
      4. Fix #14111 and #8707 by allowing the header of a data instance
         to affect kind inferece for the the data constructor signatures;
         as described at length in Note [GADT return types] in GHC.Tc.TyCl
      
         This led to a modest refactoring of the arguments (and argument
         order) of tcConDecl/tcConDecls.
      
      5. Fix #19000 by inverting the sense of the test in new_locs
         in GHC.Tc.Solver.Canonical.canDecomposableTyConAppOK.
      62ed6957
  6. 05 Dec, 2020 2 commits
  7. 04 Dec, 2020 1 commit
  8. 03 Dec, 2020 1 commit
  9. 02 Dec, 2020 9 commits
    • Ben Gamari's avatar
      41c64eb5
    • Ben Gamari's avatar
      rts/m32: Introduce NEEDS_M32 macro · c35d0e03
      Ben Gamari authored
      Instead of relying on RTS_LINKER_USE_MMAP
      c35d0e03
    • Ben Gamari's avatar
    • Ben Gamari's avatar
      rts/linker: Introduce munmapForLinker · 97d71646
      Ben Gamari authored
      Consolidates munmap calls to ensure consistent error handling.
      97d71646
    • Ben Gamari's avatar
      rts: Introduce mmapAnonForLinker · add0aeae
      Ben Gamari authored
      Previously most of the uses of mmapForLinker were mapping anonymous
      memory, resulting in a great deal of unnecessary repetition. Factor this
      out into a new helper.
      
      Also fixes a few places where error checking was missing or suboptimal.
      add0aeae
    • Richard Eisenberg's avatar
      Rename the flattener to become the rewriter. · d66660ba
      Richard Eisenberg authored
      Now that flattening doesn't produce flattening variables,
      it's not really flattening anything: it's rewriting. This
      change also means that the rewriter can no longer be confused
      the core flattener (in GHC.Core.Unify), which is sometimes used
      during type-checking.
      d66660ba
    • Richard Eisenberg's avatar
      Remove flattening variables · 8bb52d91
      Richard Eisenberg authored
      This patch redesigns the flattener to simplify type family applications
      directly instead of using flattening meta-variables and skolems. The key new
      innovation is the CanEqLHS type and the new CEqCan constraint (Ct). A CanEqLHS
      is either a type variable or exactly-saturated type family application; either
      can now be rewritten using a CEqCan constraint in the inert set.
      
      Because the flattener no longer reduces all type family applications to
      variables, there was some performance degradation if a lengthy type family
      application is now flattened over and over (not making progress). To
      compensate, this patch contains some extra optimizations in the flattener,
      leading to a number of performance improvements.
      
      Close #18875.
      Close #18910.
      
      There are many extra parts of the compiler that had to be affected in writing
      this patch:
      
      * The family-application cache (formerly the flat-cache) sometimes stores
        coercions built from Given inerts. When these inerts get kicked out, we must
        kick out from the cache as well. (This was, I believe, true previously, but
        somehow never caused trouble.) Kicking out from the cache requires adding a
        filterTM function to TrieMap.
      
      * This patch obviates the need to distinguish "blocking" coercion holes from
        non-blocking ones (which, previously, arose from CFunEqCans). There is thus
        some simplification around coercion holes.
      
      * Extra commentary throughout parts of the code I read through, to preserve
        the knowledge I gained while working.
      
      * A change in the pure unifier around unifying skolems with other types.
        Unifying a skolem now leads to SurelyApart, not MaybeApart, as documented
        in Note [Binding when looking up instances] in GHC.Core.InstEnv.
      
      * Some more use of MCoercion where appropriate.
      
      * Previously, class-instance lookup automatically noticed that e.g. C Int was
        a "unifier" to a target [W] C (F Bool), because the F Bool was flattened to
        a variable. Now, a little more care must be taken around checking for
        unifying instances.
      
      * Previously, tcSplitTyConApp_maybe would split (Eq a => a). This is silly,
        because (=>) is not a tycon in Haskell. Fixed now, but there are some
        knock-on changes in e.g. TrieMap code and in the canonicaliser.
      
      * New function anyFreeVarsOf{Type,Co} to check whether a free variable
        satisfies a certain predicate.
      
      * Type synonyms now remember whether or not they are "forgetful"; a forgetful
        synonym drops at least one argument. This is useful when flattening; see
        flattenView.
      
      * The pattern-match completeness checker invokes the solver. This invocation
        might need to look through newtypes when checking representational equality.
        Thus, the desugarer needs to keep track of the in-scope variables to know
        what newtype constructors are in scope. I bet this bug was around before but
        never noticed.
      
      * Extra-constraints wildcards are no longer simplified before printing.
        See Note [Do not simplify ConstraintHoles] in GHC.Tc.Solver.
      
      * Whether or not there are Given equalities has become slightly subtler.
        See the new HasGivenEqs datatype.
      
      * Note [Type variable cycles in Givens] in GHC.Tc.Solver.Canonical
        explains a significant new wrinkle in the new approach.
      
      * See Note [What might match later?] in GHC.Tc.Solver.Interact, which
        explains the fix to #18910.
      
      * The inert_count field of InertCans wasn't actually used, so I removed
        it.
      
      Though I (Richard) did the implementation, Simon PJ was very involved
      in design and review.
      
      This updates the Haddock submodule to avoid #18932 by adding
      a type signature.
      
      -------------------------
      Metric Decrease:
          T12227
          T5030
          T9872a
          T9872b
          T9872c
      Metric Increase:
          T9872d
      -------------------------
      8bb52d91
    • Richard Eisenberg's avatar
      Bump the # of commits searched for perf baseline · 0dd45d0a
      Richard Eisenberg authored
      The previous value of 75 meant that a feature branch with
      more than 75 commits would get spurious CI passes.
      
      This affects #18692, but does not fix that ticket, because
      if a baseline cannot be found, we should fail, not succeed.
      0dd45d0a
    • Richard Eisenberg's avatar
      Move core flattening algorithm to Core.Unify · 72a87fbc
      Richard Eisenberg authored
      This sets the stage for a later change, where this
      algorithm will be needed from GHC.Core.InstEnv.
      
      This commit also splits GHC.Core.Map into
      GHC.Core.Map.Type and GHC.Core.Map.Expr,
      in order to avoid module import cycles
      with GHC.Core.
      72a87fbc
  10. 01 Dec, 2020 7 commits