1. 18 Feb, 2021 1 commit
  2. 14 Feb, 2021 1 commit
  3. 06 Feb, 2021 1 commit
    • Simon Peyton Jones's avatar
      Fix buglet in expandSynTyCon_maybe · 18313374
      Simon Peyton Jones authored
      The fix for #17958, implemented in MR !2952, introduced a small bug
      in GHC.Core.TyCon.expandSynTyCon_maybe, in the case of under-saturated
      type synonyms.
      
      This MR fixes the bug, very easy.
      
      Fixes #19279
      18313374
  4. 07 Jan, 2021 1 commit
  5. 23 Dec, 2020 1 commit
    • Sebastian Graf's avatar
      WorkWrap: Unbox constructors with existentials (#18982) · f0ec06c7
      Sebastian Graf authored
      Consider
      
      ```hs
      data Ex where
        Ex :: e -> Int -> Ex
      
      f :: Ex -> Int
      f (Ex e n) = e `seq` n + 1
      ```
      
      Worker/wrapper should build the following worker for `f`:
      
      ```hs
      $wf :: forall e. e -> Int# -> Int#
      $wf e n = e `seq` n +# 1#
      ```
      
      But previously it didn't, because `Ex` binds an existential.
      This patch lifts that condition. That entailed having to instantiate
      existential binders in `GHC.Core.Opt.WorkWrap.Utils.mkWWstr` via
      `GHC.Core.Utils.dataConRepFSInstPat`, requiring a bit of a refactoring
      around what is now `DataConPatContext`.
      
      CPR W/W still won't unbox DataCons with existentials.
      See `Note [Which types are unboxed?]` for details.
      
      I also refactored the various `tyCon*DataCon(s)_maybe` functions in
      `GHC.Core.TyCon`, deleting some of them which are no longer needed
      (`isDataProductType_maybe` and `isDataSumType_maybe`).
      I cleaned up a couple of call sites, some of which weren't very explicit
      about whether they cared for existentials or not.
      
      The test output of `T18013` changed, because we now unbox the `Rule`
      data type. Its constructor carries existential state and will be
      w/w'd now. In the particular example, the worker functions inlines right
      back into the wrapper, which then unnecessarily has a (quite big) stable
      unfolding. I think this kind of fallout is inevitable;
      see also Note [Don't w/w inline small non-loop-breaker things].
      
      There's a new regression test case `T18982`.
      Fixes #18982.
      f0ec06c7
  6. 15 Dec, 2020 1 commit
  7. 14 Dec, 2020 4 commits
    • Andrew Martin's avatar
      Implement BoxedRep proposal · 6c2eb223
      Andrew Martin authored
      This implements the BoxedRep proposal, refacoring the `RuntimeRep`
      hierarchy from:
      
      ```haskell
      data RuntimeRep = LiftedPtrRep | UnliftedPtrRep | ...
      ```
      
      to
      
      ```haskell
      data RuntimeRep = BoxedRep Levity | ...
      data Levity = Lifted | Unlifted
      ```
      
      Closes #17526.
      6c2eb223
    • Ben Gamari's avatar
      Optimise nullary type constructor usage · dad87210
      Ben Gamari authored
      During the compilation of programs GHC very frequently deals with
      the `Type` type, which is a synonym of `TYPE 'LiftedRep`. This patch
      teaches GHC to avoid expanding the `Type` synonym (and other nullary
      type synonyms) during type comparisons, saving a good amount of work.
      This optimisation is described in `Note [Comparing nullary type
      synonyms]`.
      
      To maximize the impact of this optimisation, we introduce a few
      special-cases to reduce `TYPE 'LiftedRep` to `Type`. See
      `Note [Prefer Type over TYPE 'LiftedPtrRep]`.
      
      Closes #17958.
      
      Metric Decrease:
         T18698b
         T1969
         T12227
         T12545
         T12707
         T14683
         T3064
         T5631
         T5642
         T9020
         T9630
         T9872a
         T13035
         haddock.Cabal
         haddock.base
      dad87210
    • Ben Gamari's avatar
      Revert "Optimise nullary type constructor usage" · 92377c27
      Ben Gamari authored
      This was inadvertently merged.
      
      This reverts commit 7e9debd4.
      92377c27
    • Ben Gamari's avatar
      Optimise nullary type constructor usage · 7e9debd4
      Ben Gamari authored
      During the compilation of programs GHC very frequently deals with
      the `Type` type, which is a synonym of `TYPE 'LiftedRep`. This patch
      teaches GHC to avoid expanding the `Type` synonym (and other nullary
      type synonyms) during type comparisons, saving a good amount of work.
      This optimisation is described in `Note [Comparing nullary type
      synonyms]`.
      
      To maximize the impact of this optimisation, we introduce a few
      special-cases to reduce `TYPE 'LiftedRep` to `Type`. See
      `Note [Prefer Type over TYPE 'LiftedPtrRep]`.
      
      Closes #17958.
      
      Metric Decrease:
         T18698b
         T1969
         T12227
         T12545
         T12707
         T14683
         T3064
         T5631
         T5642
         T9020
         T9630
         T9872a
         T13035
         haddock.Cabal
         haddock.base
      7e9debd4
  8. 02 Dec, 2020 1 commit
    • 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
        kic...
      8bb52d91
  9. 26 Nov, 2020 1 commit
    • Sylvain Henry's avatar
      Fix toArgRep to support 64-bit reps on all systems · cdbd16f5
      Sylvain Henry authored
      [This is @Ericson2314 writing a commit message for @hsyl20's patch.]
      
      (Progress towards #11953, #17377, #17375)
      
      `Int64Rep` and `Word64Rep` are currently broken on 64-bit systems.  This
      is because they should use "native arg rep" but instead use "large arg
      rep" as they do on 32-bit systems, which is either a non-concept or a
      128-bit rep depending on one's vantage point.
      
      Now, these reps currently aren't used during 64-bit compilation, so the
      brokenness isn't observed, but I don't think that constitutes reasons
      not to fix it. Firstly, the linked issues there is a clearly expressed
      desire to use explicit-bitwidth constructs in more places. Secondly, per
      [1], there are other bugs that *do* manifest from not threading
      explicit-bitwidth information all the way through the compilation
      pipeline. One can therefore view this as one piece of the larger effort
      to do that, improve ergnomics, and squash remaining bugs.
      
      Also, this is needed for !3658. I could just merge this as part of that,
      but I'm keen on merging fixes "as they are ready" so the fixes that
      aren't ready are isolated and easier to debug.
      
      [1]: https://mail.haskell.org/pipermail/ghc-devs/2020-October/019332.html
      cdbd16f5
  10. 30 Oct, 2020 1 commit
    • Richard Eisenberg's avatar
      Remove unnecessary gender from comments/docs · 7f8be3eb
      Richard Eisenberg authored
      While, say, alternating "he" and "she" in sequential writing
      may be nicer than always using "they", reading code/documentation
      is almost never sequential. If this small change makes individuals
      feel more welcome in GHC's codebase, that's a good thing.
      7f8be3eb
  11. 10 Oct, 2020 1 commit
  12. 09 Oct, 2020 1 commit
    • Andreas Klebinger's avatar
      Add TyCon Set/Env and use them in a few places. · ef950b19
      Andreas Klebinger authored
      Firstly this improves code clarity.
      
      But it also has performance benefits as we no longer
      go through the name of the TyCon to get at it's unique.
      
      In order to make this work the recursion check for TyCon
      has been moved into it's own module in order to avoid import
      cycles.
      ef950b19
  13. 24 Sep, 2020 1 commit
    • Simon Peyton Jones's avatar
      Improve kind generalisation, error messages · 9fa26aa1
      Simon Peyton Jones authored
      This patch does two things:
      
      * It refactors GHC.Tc.Errors a bit.  In debugging Quick Look I was
        forced to look in detail at error messages, and ended up doing a bit
        of refactoring, esp in mkTyVarEqErr'.  It's still quite a mess, but
        a bit better, I think.
      
      * It makes a significant improvement to the kind checking of type and
        class declarations. Specifically, we now ensure that if kind
        checking fails with an unsolved constraint, all the skolems are in
        scope.  That wasn't the case before, which led to some obscure error
        messages; and occasional failures with "no skolem info" (eg #16245).
      
      Both of these, and the main Quick Look patch itself, affect a /lot/ of
      error messages, as you can see from the number of files changed.  I've
      checked them all; I think they are as good or better than before.
      
      Smaller things
      
      * I documented the various instances of VarBndr better.
        See Note [The VarBndr tyep and its uses] in GHC.Types.Var
      
      * Renamed GHC.Tc.Solver.simpl_top to simplifyTopWanteds
      
      * A bit of refactoring in bindExplicitTKTele, to avoid the
        footwork with Either.  Simpler now.
      
      * Move promoteTyVar from GHC.Tc.Solver to GHC.Tc.Utils.TcMType
      
      Fixes #16245 (comment 211369), memorialised as
        typecheck/polykinds/T16245a
      Also fixes the three bugs in #18640
      9fa26aa1
  14. 04 Sep, 2020 1 commit
    • Ryan Scott's avatar
      Introduce isBoxedTupleDataCon and use it to fix #18644 · c1e54439
      Ryan Scott authored
      The code that converts promoted tuple data constructors to
      `IfaceType`s in `GHC.CoreToIface` was using `isTupleDataCon`, which
      conflates boxed and unboxed tuple data constructors. To avoid this,
      this patch introduces `isBoxedTupleDataCon`, which is like
      `isTupleDataCon` but only works for _boxed_ tuple data constructors.
      
      While I was in town, I was horribly confused by the fact that there
      were separate functions named `isUnboxedTupleCon` and
      `isUnboxedTupleTyCon` (similarly, `isUnboxedSumCon` and
      `isUnboxedSumTyCon`). It turns out that the former only works for
      data constructors, despite its very general name! I opted to rename
      `isUnboxedTupleCon` to `isUnboxedTupleDataCon` (similarly, I renamed
      `isUnboxedSumCon` to `isUnboxedSumDataCon`) to avoid this potential
      confusion, as well as to be more consistent with
      the naming convention I used for `isBoxedTupleDataCon`.
      
      Fixes #18644.
      c1e54439
  15. 22 Aug, 2020 1 commit
    • Aditya Gupta's avatar
      mkUnique refactoring (#18362) · e67ae884
      Aditya Gupta authored
      Move uniqFromMask from Unique.Supply to Unique.
      Move the the functions that call mkUnique from Unique to Builtin.Uniques
      e67ae884
  16. 12 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: disentangle Outputable · accbc242
      Sylvain Henry authored
      - put panic related functions into GHC.Utils.Panic
      - put trace related functions using DynFlags in GHC.Driver.Ppr
      
      One step closer making Outputable fully independent of DynFlags.
      
      Bump haddock submodule
      accbc242
  17. 03 Jul, 2020 1 commit
    • Simon Peyton Jones's avatar
      Improve handling of data type return kinds · 4bf18646
      Simon Peyton Jones authored
      Following a long conversation with Richard, this patch tidies up the
      handling of return kinds for data/newtype declarations (vanilla,
      family, and instance).
      
      I have substantially edited the Notes in TyCl, so they would
      bear careful reading.
      
      Fixes #18300, #18357
      
      In GHC.Tc.Instance.Family.newFamInst we were checking some Lint-like
      properties with ASSSERT.  Instead Richard and I have added
      a proper linter for axioms, and called it from lintGblEnv, which in
      turn is called in tcRnModuleTcRnM
      
      New tests (T18300, T18357) cause an ASSERT failure in HEAD.
      4bf18646
  18. 28 Jun, 2020 1 commit
  19. 25 Jun, 2020 1 commit
    • Takenobu Tani's avatar
      Clean up haddock hyperlinks of GHC.* (part1) · c7dd6da7
      Takenobu Tani authored
      This updates haddock comments only.
      
      This patch focuses to update for hyperlinks in GHC API's haddock comments,
      because broken links especially discourage newcomers.
      
      This includes the following hierarchies:
        - GHC.Hs.*
        - GHC.Core.*
        - GHC.Stg.*
        - GHC.Cmm.*
        - GHC.Types.*
        - GHC.Data.*
        - GHC.Builtin.*
        - GHC.Parser.*
        - GHC.Driver.*
        - GHC top
      c7dd6da7
  20. 17 Jun, 2020 2 commits
    • 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
      * S...
      40fa237e
  21. 01 Jun, 2020 2 commits
  22. 21 May, 2020 1 commit
    • Gert-Jan Bottu's avatar
      Explicit Specificity · a9311cd5
      Gert-Jan Bottu authored
      Implementation for Ticket #16393.
      Explicit specificity allows users to manually create inferred type variables,
      by marking them with braces.
      This way, the user determines which variables can be instantiated through
      visible type application.
      
      The additional syntax is included in the parser, allowing users to write
      braces in type variable binders (type signatures, data constructors etc).
      This information is passed along through the renamer and verified in the
      type checker.
      The AST for type variable binders, data constructors, pattern synonyms,
      partial signatures and Template Haskell has been updated to include the
      specificity of type variables.
      
      Minor notes:
      - Bumps haddock submodule
      - Disables pattern match checking in GHC.Iface.Type with GHC 8.8
      a9311cd5
  23. 01 May, 2020 1 commit
    • Sylvain Henry's avatar
      Fully remove PprDebug · de9fc995
      Sylvain Henry authored
      PprDebug was a pain to deal with consistently as it is implied by
      `-dppr-debug` but it isn't really a PprStyle. We remove it completely
      and query the appropriate SDoc flag instead (`sdocPprDebug`) via
      helpers (`getPprDebug` and its friends).
      de9fc995
  24. 30 Apr, 2020 1 commit
  25. 26 Apr, 2020 1 commit
  26. 18 Apr, 2020 1 commit
    • Sylvain Henry's avatar
      Modules (#13009) · 15312bbb
      Sylvain Henry authored
      * SysTools
      * Parser
      * GHC.Builtin
      * GHC.Iface.Recomp
      * Settings
      
      Update Haddock submodule
      
      Metric Decrease:
          Naperian
          parsing001
      15312bbb
  27. 10 Apr, 2020 1 commit
    • Sebastian Graf's avatar
      Special case `isConstraintKindCon` on `AlgTyCon` · 101fab6e
      Sebastian Graf authored
      Previously, the `tyConUnique` record selector would unfold into a huge
      case expression that would be inlined in all call sites, such as the
      `INLINE`-annotated `coreView`, see #18026. `constraintKindTyConKey` only
      occurs as the `Unique` of an `AlgTyCon` anyway, so we can make the code
      a lot more compact, but have to move it to GHC.Core.TyCon.
      
      Metric Decrease:
          T12150
          T12234
      101fab6e
  28. 07 Apr, 2020 1 commit
  29. 01 Apr, 2020 1 commit
    • Ryan Scott's avatar
      Clean up "Eta reduction for data families" Notes · 9b39f2e6
      Ryan Scott authored
      Before, there were two distinct Notes named
      "Eta reduction for data families". This renames one of them to
      "Implementing eta reduction for data families" to disambiguate the
      two and fixes references in other parts of the codebase to ensure
      that they are pointing to the right place.
      
      Fixes #17313.
      
      [ci skip]
      9b39f2e6
  30. 29 Mar, 2020 1 commit
  31. 26 Mar, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags refactoring III · 0de03cd7
      Sylvain Henry authored
      Use Platform instead of DynFlags when possible:
      * `tARGET_MIN_INT` et al. replaced with `platformMinInt` et al.
      * no more DynFlags in PreRules: added a new `RuleOpts` datatype
      * don't use `wORD_SIZE` in the compiler
      * make `wordAlignment` use `Platform`
      * make `dOUBLE_SIZE` a constant
      
      Metric Decrease:
          T13035
          T1969
      0de03cd7
  32. 17 Mar, 2020 1 commit
  33. 26 Feb, 2020 1 commit
  34. 22 Feb, 2020 1 commit
  35. 21 Feb, 2020 1 commit
    • Simon Peyton Jones's avatar
      Re-implement unsafe coercions in terms of unsafe equality proofs · 74ad75e8
      Simon Peyton Jones authored
      (Commit message written by Omer, most of the code is written by Simon
      and Richard)
      
      See Note [Implementing unsafeCoerce] for how unsafe equality proofs and
      the new unsafeCoerce# are implemented.
      
      New notes added:
      
      - [Checking for levity polymorphism] in CoreLint.hs
      - [Implementing unsafeCoerce] in base/Unsafe/Coerce.hs
      - [Patching magic definitions] in Desugar.hs
      - [Wiring in unsafeCoerce#] in Desugar.hs
      
      Only breaking change in this patch is unsafeCoerce# is not exported from
      GHC.Exts, instead of GHC.Prim.
      
      Fixes #17443
      Fixes #16893
      
      NoFib
      -----
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs    Instrs     Reads    Writes
      --------------------------------------------------------------------------------
                   CS          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  CSD          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                   FS          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                    S          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                   VS          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  VSD          -0.1%      0.0%     -0.0%     -0.0%     -0.1%
                  VSM          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 anna          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 ansi          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 atom          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               awards          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               banner          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
           bernouilli          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         binary-trees          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                boyer          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               boyer2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 bspt          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            cacheprof          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             calendar          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             cichelli          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              circsim          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             clausify          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
        comp_lab_zift          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             compress          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            compress2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
          constraints          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         cryptarithm1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         cryptarithm2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  cse          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               dom-lt          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                eliza          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                event          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
          exact-reals          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               exp3_8          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               expert          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
       fannkuch-redux          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                fasta          -0.1%      0.0%     -0.5%     -0.3%     -0.4%
                  fem          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  fft          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 fft2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             fibheaps          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 fish          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                fluid          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               fulsom          -0.1%      0.0%     +0.0%     +0.0%     +0.0%
               gamteb          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  gcd          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
          gen_regexps          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               genfft          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                   gg          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 grep          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               hidden          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  hpg          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  ida          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                infer          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              integer          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            integrate          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         k-nucleotide          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                kahan          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              knights          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               lambda          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
           last-piece          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 lcss          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 life          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 lift          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               linear          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            listcompr          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             listcopy          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             maillist          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               mandel          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              mandel2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 mate          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              minimax          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              mkhprog          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
           multiplier          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               n-body          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             nucleic2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 para          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            paraffins          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               parser          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              parstof          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  pic          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             pidigits          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                power          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               pretty          -0.1%      0.0%     -0.1%     -0.1%     -0.1%
               primes          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            primetest          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               prolog          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               puzzle          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               queens          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              reptile          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
      reverse-complem          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              rewrite          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 rfib          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  rsa          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  scc          -0.1%      0.0%     -0.1%     -0.1%     -0.1%
                sched          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  scs          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               simple          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                solid          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              sorting          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
        spectral-norm          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               sphere          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               symalg          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  tak          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            transform          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             treejoin          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            typecheck          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              veritas          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 wang          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            wave4main          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 x2n1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
      --------------------------------------------------------------------------------
                  Min          -0.1%      0.0%     -0.5%     -0.3%     -0.4%
                  Max          -0.0%      0.0%     +0.0%     +0.0%     +0.0%
       Geometric Mean          -0.1%     -0.0%     -0.0%     -0.0%     -0.0%
      
      Test changes
      ------------
      
      - break006 is marked as broken, see #17833
      
      
      - The compiler allocates less when building T14683 (an unsafeCoerce#-
        heavy happy-generated code) on 64-platforms. Allocates more on 32-bit
        platforms.
      - Rest of the increases are tiny amounts (still enough to pass the
        threshold) in micro-benchmarks. I briefly looked at each one in a
        profiling build: most of the increased allocations seem to be because
        of random changes in the generated code.
      
      Metric Decrease:
          T14683
      
      Metric Increase:
          T12150
          T12234
          T12425
          T13035
          T14683
          T5837
          T6048
      Co-Authored-By: Richard Eisenberg's avatarRichard Eisenberg <rae@cs.brynmawr.edu>
      Co-Authored-By: Ömer Sinan Ağacan's avatarÖmer Sinan Ağacan <omeragacan@gmail.com>
      74ad75e8