1. 24 Jun, 2020 2 commits
    • Sylvain Henry's avatar
      Cmm: introduce SAVE_REGS/RESTORE_REGS · 7750bd45
      Sylvain Henry authored
      We don't want to save both Fn and Dn register sets on x86-64 as they are
      aliased to the same arch register (XMMn).
      Moreover, when SAVE_STGREGS was used in conjunction with `jump foo [*]`
      which makes a set of Cmm registers alive so that they cover all arch
      registers used to pass parameter, we could have Fn, Dn and XMMn alive at
      the same time. It made the LLVM code generator choke (see #17920).
      Now `SAVE_REGS/RESTORE_REGS` and `jump foo [*]` use the same set of
    • John Ericson's avatar
      Switch from HscSource to IsBootInterface for module lookup in GhcMake · 809caedf
      John Ericson authored
      We look up modules by their name, and not their contents. There is no
      way to separately reference a signature vs regular module; you get what
      you get. Only boot files can be referenced indepenently with `import {-#
      SOURCE #-}`.
  2. 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
    • 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.
    • Tamar Christina's avatar
    • Ö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== 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)
              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
    • 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.
    • Sylvain Henry's avatar
    • Adam Sandberg Eriksson's avatar
      docs: mention -hiedir in docs for -outputdir · 1a3f6f34
      Adam Sandberg Eriksson authored
      [skip ci]
  3. 17 Jun, 2020 16 commits
    • Sylvain Henry's avatar
      Bump bytestring and text submodules · fa4281d6
      Sylvain Henry authored
    • 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
    • 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
      * fix test results showing dependent packages (e.g. integer-gmp) or
        showing suggested instances
      * fix test using Integer/Natural API or showing internal names
    • Sylvain Henry's avatar
      Update `make` based build system · aa9e7b71
      Sylvain Henry authored
      * replace integer-* package selection with ghc-bignum backend selection
    • 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
    • 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.
    • 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"
      * 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...
    • 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
    • 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:
      Metric Increase:
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored
      This is the first step towards implementation of the linear types proposal
      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
      * S...
    • Ben Gamari's avatar
      configure: Use grep -q instead of --quiet · 20616959
      Ben Gamari authored
      The latter is apparently not supported by busybox.
    • Ben Gamari's avatar
      base: Bump to · 7faa4509
      Ben Gamari authored
    • 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.
    • Adam Sandberg Eriksson's avatar
    • 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%.
    • Stefan Schulze Frielinghaus's avatar
  4. 16 Jun, 2020 3 commits
  5. 15 Jun, 2020 3 commits
  6. 14 Jun, 2020 7 commits
  7. 13 Jun, 2020 1 commit
    • 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.