1. 17 Jun, 2020 13 commits
    • Sylvain Henry's avatar
      Update `make` based build system · aa9e7b71
      Sylvain Henry authored
      * replace integer-* package selection with ghc-bignum backend selection
      aa9e7b71
    • Sylvain Henry's avatar
      Update `base` package · 0f67e344
      Sylvain Henry authored
      * GHC.Natural isn't implemented in `base` anymore. It is provided by
        ghc-bignum in GHC.Num.Natural. It means that we can safely use Natural
        primitives in `base` without fearing issues with built-in rewrite
        rules (cf #15286)
      
      * `base` doesn't conditionally depend on an integer-* package anymore,
        it depends on ghc-bignum
      
      * Some duplicated code in integer-* can now be factored in GHC.Float
      
      * ghc-bignum tries to use a uniform naming convention so most of the
        other changes are renaming
      0f67e344
    • Sylvain Henry's avatar
      Update compiler · 96aa5787
      Sylvain Henry authored
      Thanks to ghc-bignum, the compiler can be simplified:
      
      * Types and constructors of Integer and Natural can be wired-in. It
        means that we don't have to query them from interfaces. It also means
        that numeric literals don't have to carry their type with them.
      
      * The same code is used whatever ghc-bignum backend is enabled. In
        particular, conversion of bignum literals into final Core expressions
        is now much more straightforward. Bignum closure inspection too.
      
      * GHC itself doesn't depend on any integer-* package anymore
      
      * The `integerLibrary` setting is gone.
      96aa5787
    • Sylvain Henry's avatar
      ghc-bignum library · 9f96bc12
      Sylvain Henry authored
      ghc-bignum is a newer package that aims to replace the legacy
      integer-simple and integer-gmp packages.
      
      * it supports several backends. In particular GMP is still supported and
        most of the code from integer-gmp has been merged in the "gmp"
        backend.
      
      * the pure Haskell "native" backend is new and is much faster than the
        previous pure Haskell implementation provided by integer-simple
      
      * new backends are easier to write because they only have to provide a
        few well defined functions. All the other code is common to all
        backends. In particular they all share the efficient small/big number
        distinction previously used only in integer-gmp.
      
      * backends can all be tested against the "native" backend with a simple
        Cabal flag. Backends are only allowed to differ in performance, their
        results should be the same.
      
      * Add `integer-gmp` compat package: provide some pattern synonyms and
        function aliases for those in `ghc-bignum`. It is intended to avoid
        breaking packages that depend o...
      9f96bc12
    • Sylvain Henry's avatar
      Remove integer-simple · 57db91d8
      Sylvain Henry authored
      integer-simple uses lists of words (`[Word]`) to represent big numbers
      instead of ByteArray#:
      
         * it is less efficient than the newer ghc-bignum native backend
      
         * it isn't compatible with the big number representation that is now
           shared by all the ghc-bignum backends (based on the one that was
           used only in integer-gmp before).
      
      As a consequence, we simply drop integer-simple
      57db91d8
    • Krzysztof Gogolewski's avatar
      Various performance improvements · 6cb84c46
      Krzysztof Gogolewski authored
      This implements several general performance improvements to GHC,
      to offset the effect of the linear types change.
      
      General optimisations:
      - Add a `coreFullView` function which iterates `coreView` on the
        head. This avoids making function recursive solely because the
        iterate `coreView` themselves. As a consequence, this functions can
        be inlined, and trigger case-of-known constructor (_e.g._
        `kindRep_maybe`, `isLiftedRuntimeRep`, `isMultiplicityTy`,
        `getTyVar_maybe`, `splitAppTy_maybe`, `splitFunType_maybe`,
        `tyConAppTyCon_maybe`). The common pattern about all these functions
        is that they are almost always used as views, and immediately
        consumed by a case expression. This commit also mark them asx `INLINE`.
      - In `subst_ty` add a special case for nullary `TyConApp`, which avoid
        allocations altogether.
      - Use `mkTyConApp` in `subst_ty` for the general `TyConApp`. This
        required quite a bit of module shuffling.
        case. `myTyConApp` enforces crucial sharing, whi...
      6cb84c46
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored
      This is the first step towards implementation of the linear types proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/111).
      
      It features
      
      * A language extension -XLinearTypes
      * Syntax for linear functions in the surface language
      * Linearity checking in Core Lint, enabled with -dlinear-core-lint
      * Core-to-core passes are mostly compatible with linearity
      * Fields in a data type can be linear or unrestricted; linear fields
        have multiplicity-polymorphic constructors.
        If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
      
      The following items are not yet supported:
      
      * a # m -> b syntax (only prefix FUN is supported for now)
      * Full multiplicity inference (multiplicities are really only checked)
      * Decent linearity error messages
      * Linear let, where, and case expressions in the surface language
        (each of these currently introduce the unrestricted variant)
      * Multiplicity-parametric fields
      * Syntax for annotating lambda-bound or let-bound with a multiplicity
      * Syntax for non-linear/multiple-field-multiplicity records
      * Linear projections for records with a single linear field
      * Linear pattern synonyms
      * Multiplicity coercions (test LinearPolyType)
      
      A high-level description can be found at
      https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Implementation
      Following the link above you will find a description of the changes made to Core.
      This commit has been authored by
      
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Matthew Pickering
      * Arnaud Spiwack
      
      With contributions from:
      
      * Mark Barbone
      * Alexander Vershilov
      
      Updates haddock submodule.
      40fa237e
    • Ben Gamari's avatar
      configure: Use grep -q instead of --quiet · 20616959
      Ben Gamari authored
      The latter is apparently not supported by busybox.
      20616959
    • Ben Gamari's avatar
      base: Bump to 4.15.0.0 · 7faa4509
      Ben Gamari authored
      7faa4509
    • Sylvain Henry's avatar
      Move CLabel assertions into smart constructors (#17957) · eb8115a8
      Sylvain Henry authored
      It avoids using DynFlags in the Outputable instance of Clabel to check
      assertions at pretty-printing time.
      eb8115a8
    • Adam Sandberg Eriksson's avatar
      4cab6897
    • Sylvain Henry's avatar
      T16190: only measure bytes_allocated · 0639dc10
      Sylvain Henry authored
      Just adding `{-# LANGUAGE BangPatterns #-}` makes the two other metrics
      fluctuate by 13%.
      0639dc10
    • Stefan Schulze Frielinghaus's avatar
      d23fc678
  2. 16 Jun, 2020 3 commits
  3. 15 Jun, 2020 3 commits
  4. 14 Jun, 2020 7 commits
  5. 13 Jun, 2020 14 commits
    • Ryan Scott's avatar
      Use HsForAllTelescope to avoid inferred, visible foralls · a31218f7
      Ryan Scott authored
      Currently, `HsForAllTy` permits the combination of `ForallVis` and
      `Inferred`, but you can't actually typecheck code that uses it
      (e.g., `forall {a} ->`). This patch refactors `HsForAllTy` to use a
      new `HsForAllTelescope` data type that makes a type-level distinction
      between visible and invisible `forall`s such that visible `forall`s
      do not track `Specificity`. That part of the patch is actually quite
      small; the rest is simply changing consumers of `HsType` to
      accommodate this new type.
      
      Fixes #18235. Bumps the `haddock` submodule.
      a31218f7
    • Ben Gamari's avatar
      7a773f16
    • Ben Gamari's avatar
      gitlab-ci: Always push perf notes · 8bba1c26
      Ben Gamari authored
      Previously we ci.sh would run with `set -e` implying that we wouldn't
      push perf notes if the testsuite were to fail, even if it *only* failed
      due to perf notes. This rendered the whole performance testing story
      quite fragile as a single regressing commit would cause every successive
      commit to fail since a new baseline would not be uploaded.
      
      Fix this by ensuring that we always push performance notes.
      8bba1c26
    • Ben Gamari's avatar
      testsuite: Increase size of T12150 · 220c2d34
      Ben Gamari authored
      As noted in #18319, this test was previously very fragile. Increase its
      size to make it more likely that its fails with its newly-increased
      acceptance threshold.
      
      Metric Increase:
          T12150
      220c2d34
    • Oleg Grenrus's avatar
      Fix #12073: Add MonadFix Q instance · 9f09b608
      Oleg Grenrus authored
      9f09b608
    • vdukhovni's avatar
      Add introductory prose for Data.Traversable · 87d504f4
      vdukhovni authored
      87d504f4
    • Simon Peyton Jones's avatar
      Trim the demand for recursive product types · 42953902
      Simon Peyton Jones authored
      Ticket #18304 showed that we need to be very careful
      when exploring the demand (esp usage demand) on recursive
      product types.
      
      This patch solves the problem by trimming the demand on such types --
      in effect, a form of "widening".
      
      See the Note [Trimming a demand to a type] in DmdAnal, which explains
      how I did this by piggy-backing on an existing mechansim for trimming
      demands becuase of GADTs.  The significant payload of this patch is
      very small indeed:
      
      * Make GHC.Core.Opt.WorkWrap.Utils.typeShape use RecTcChecker to
        avoid looking through recursive types.
      
      But on the way
      
      * I found that ae_rec_tc was entirely inoperative and did nothing.
        So I removed it altogether from DmdAnal.
      
      * I moved some code around in DmdAnal and Demand.
        (There are no actual changes in dmdFix.)
      
      * I changed the API of DmsAnal.dmdAnalRhsLetDown to return
        a StrictSig rather than a decorated Id
      
      * I removed the dead function peelTsFuns from Demand
      
      Performance effects:
      
      Nofib: 0.0% changes.  Not surprising, because they don't
             use recursive products
      
      Perf tests
      
      T12227:
        1% increase in compiler allocation, becuase $cto gets w/w'd.
        It did not w/w before because it takes a deeply nested
        argument, so the worker gets too many args, so we abandon w/w
        altogether (see GHC.Core.Opt.WorkWrap.Utils.isWorkerSmallEnough)
      
        With this patch we trim the demands.  That is not strictly
        necessary (since these Generic type constructors are like
        tuples -- they can't cause a loop) but the net result is that
        we now w/w $cto which is fine.
      
      UniqLoop:
        16% decrease in /runtime/ allocation. The UniqSupply is a
        recursive product, so currently we abandon all strictness on
        'churn'.  With this patch 'churn' gets useful strictness, and
        we w/w it.  Hooray
      
      Metric Decrease:
          UniqLoop
      
      Metric Increase:
          T12227
      42953902
    • Sylvain Henry's avatar
      Bump haddock submodule and allow metric decrease · 456e17f0
      Sylvain Henry authored
      Metric Decrease:
          T12150
          T12234
          T5837
      
      Metric Increase:
          T16190
      456e17f0
    • Sylvain Henry's avatar
      Doc: fix some comments · c10ff7e7
      Sylvain Henry authored
      c10ff7e7
    • Sylvain Henry's avatar
      NCGConfig: remove useless ncgUnitId field · 1fbb4bf5
      Sylvain Henry authored
      1fbb4bf5
    • Sylvain Henry's avatar
      Don't return preload units when we set DyNFlags · bfd0a78c
      Sylvain Henry authored
      Preload units can be retrieved in UnitState when needed (i.e. in GHCi)
      bfd0a78c
    • Sylvain Henry's avatar
      Put database cache in UnitConfig · ac964c83
      Sylvain Henry authored
      ac964c83
    • Sylvain Henry's avatar
      28d804e1
    • Sylvain Henry's avatar
      Move distrustAll into mkUnitState · 4274688a
      Sylvain Henry authored
      4274688a