1. 19 Jun, 2020 8 commits
    • Sylvain Henry's avatar
      Move tablesNextToCode field into Platform · d4a0be75
      Sylvain Henry authored
      tablesNextToCode is a platform setting and doesn't belong into DynFlags
      (#17957). Doing this is also a prerequisite to fix #14335 where we deal
      with two platforms (target and host) that may have different platform
      settings.
      d4a0be75
    • Sylvain Henry's avatar
      DynFlags: store default depth in SDocContext (#17957) · 2af0ec90
      Sylvain Henry authored
      It avoids having to use DynFlags to reach for pprUserLength.
      2af0ec90
    • Tamar Christina's avatar
      da18ff99
    • Ömer Sinan Ağacan's avatar
      Fix uninitialized field read in Linker.c · 08c1cb0f
      Ömer Sinan Ağacan authored
      Valgrind report of the bug when running the test `linker_unload`:
      
          ==29666== Conditional jump or move depends on uninitialised value(s)
          ==29666==    at 0x369C5B4: setOcInitialStatus (Linker.c:1305)
          ==29666==    by 0x369C6C5: mkOc (Linker.c:1347)
          ==29666==    by 0x36C027A: loadArchive_ (LoadArchive.c:522)
          ==29666==    by 0x36C0600: loadArchive (LoadArchive.c:626)
          ==29666==    by 0x2C144CD: ??? (in /home/omer/haskell/ghc_2/testsuite/tests/rts/linker/linker_unload.run/linker_unload)
          ==29666==
          ==29666== Conditional jump or move depends on uninitialised value(s)
          ==29666==    at 0x369C5B4: setOcInitialStatus (Linker.c:1305)
          ==29666==    by 0x369C6C5: mkOc (Linker.c:1347)
          ==29666==    by 0x369C9F6: preloadObjectFile (Linker.c:1507)
          ==29666==    by 0x369CA8D: loadObj_ (Linker.c:1536)
          ==29666==    by 0x369CB17: loadObj (Linker.c:1557)
          ==29666==    by 0x3866BC: main (linker_unload.c:33)
      
      The problem is `mkOc` allocates a new `ObjectCode` and calls
      `setOcInitialStatus` without initializing the `status` field.
      `setOcInitialStatus` reads the field as first thing:
      
          static void setOcInitialStatus(ObjectCode* oc) {
              if (oc->status == OBJECT_DONT_RESOLVE)
                return;
      
              if (oc->archiveMemberName == NULL) {
                  oc->status = OBJECT_NEEDED;
              } else {
                  oc->status = OBJECT_LOADED;
              }
          }
      
      `setOcInitialStatus` is unsed in two places for two different purposes:
      in `mkOc` where we don't have the `status` field initialized yet (`mkOc`
      is supposed to initialize it), and `loadOc` where we do have `status`
      field initialized and we want to update it. Instead of splitting the
      function into two functions which are both called just once I inline the
      functions in the use sites and remove it.
      
      Fixes #18342
      08c1cb0f
    • Sebastian Graf's avatar
    • Andreas Klebinger's avatar
      Relax allocation threshold for T12150. · 95e18292
      Andreas Klebinger authored
      This test performs little work, so the most minor allocation
      changes often cause the test to fail.
      
      Increasing the threshold to 2% should help with this.
      95e18292
    • Sylvain Henry's avatar
      729bcb02
    • Adam Sandberg Eriksson's avatar
      docs: mention -hiedir in docs for -outputdir · 1a3f6f34
      Adam Sandberg Eriksson authored
      [skip ci]
      1a3f6f34
  2. 17 Jun, 2020 16 commits
    • Sylvain Henry's avatar
      Bump bytestring and text submodules · fa4281d6
      Sylvain Henry authored
      fa4281d6
    • Sylvain Henry's avatar
      Update Hadrian · dceecb09
      Sylvain Henry authored
      * support ghc-bignum backend selection in flavours and command-line
      
      * support ghc-bignum "--check" flag (compare results of selected backend
        against results of the native one) in flavours and command-line (e.g.
        pass --bignum=check-gmp" to check the "gmp" backend)
      
      * remove the hack to workaround #15286
      
      * build GMP only when the gmp backend is used
      
      * remove hacks to workaround `text` package flags about integer-*. We
        fix `text` to use ghc-bignum unconditionally in another patch
      dceecb09
    • Sylvain Henry's avatar
      Update testsuite · f817d816
      Sylvain Henry authored
      * support detection of slow ghc-bignum backend (to replace the detection
        of integer-simple use). There are still some test cases that the
        native backend doesn't handle efficiently enough.
      
      * remove tests for GMP only functions that have been removed from
        ghc-bignum
      
      * fix test results showing dependent packages (e.g. integer-gmp) or
        showing suggested instances
      
      * fix test using Integer/Natural API or showing internal names
      f817d816
    • 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, which was lost during
        substitution. See also !2952 .
      - Make `subst_ty` stricter.
      - In `eqType` (specifically, in `nonDetCmpType`), add a special case,
        tested first, for the very common case of nullary `TyConApp`.
        `nonDetCmpType` has been made `INLINE` otherwise it is actually a
        regression. This is similar to the optimisations in !2952.
      
      Linear-type specific optimisations:
      - Use `tyConAppTyCon_maybe` instead of the more complex `eqType` in
        the definition of the pattern synonyms `One` and `Many`.
      - Break the `hs-boot` cycles between `Multiplicity.hs` and `Type.hs`:
        `Multiplicity` now import `Type` normally, rather than from the
        `hs-boot`. This way `tyConAppTyCon_maybe` can inline properly in the
        `One` and `Many` pattern synonyms.
      - Make `updateIdTypeAndMult` strict in its type and multiplicity
      - The `scaleIdBy` gets a specialised definition rather than being an
        alias to `scaleVarBy`
      - `splitFunTy_maybe` is given the type `Type -> Maybe (Mult, Type,
        Type)` instead of `Type -> Maybe (Scaled Type, Type)`
      - Remove the `MultMul` pattern synonym in favour of a view `isMultMul`
        because pattern synonyms appear not to inline well.
      - in `eqType`, in a `FunTy`, compare multiplicities last: they are
        almost always both `Many`, so it helps failing faster.
      - Cache `manyDataConTy` in `mkTyConApp`, to make sure that all the
        instances of `TyConApp ManyDataConTy []` are physically the same.
      
      This commit has been authored by
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Arnaud Spiwack
      
      Metric Decrease:
          haddock.base
          T12227
          T12545
          T12990
          T1969
          T3064
          T5030
          T9872b
      
      Metric Increase:
          haddock.base
          haddock.Cabal
          haddock.compiler
          T12150
          T12234
          T12425
          T12707
          T13035
          T13056
          T15164
          T16190
          T18304
          T1969
          T3064
          T3294
          T5631
          T5642
          T5837
          T6048
          T9020
          T9233
          T9675
          T9872a
          T9961
          WWRec
      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
  3. 16 Jun, 2020 3 commits
  4. 15 Jun, 2020 3 commits
  5. 14 Jun, 2020 7 commits
  6. 13 Jun, 2020 3 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