1. 28 Nov, 2020 1 commit
    • John Ericson's avatar
      Cleanup some primop constructor names · c82bc8e9
      John Ericson authored
      Harmonize the internal (big sum type) names of the native vs fixed-sized
      number primops a bit. (Mainly by renaming the former.)
      
      No user-facing names are changed.
      c82bc8e9
  2. 26 Nov, 2020 2 commits
    • 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
    • Moritz Angermann's avatar
      [Sized Cmm] properly retain sizes. · be5d74ca
      Moritz Angermann authored
      This replaces all Word<N> = W<N># Word# and Int<N> = I<N># Int#  with
      Word<N> = W<N># Word<N># and Int<N> = I<N># Int<N>#, thus providing us
      with properly sized primitives in the codegenerator instead of pretending
      they are all full machine words.
      
      This came up when implementing darwinpcs for arm64.  The darwinpcs reqires
      us to pack function argugments in excess of registers on the stack.  While
      most procedure call standards (pcs) assume arguments are just passed in
      8 byte slots; and thus the caller does not know the exact signature to make
      the call, darwinpcs requires us to adhere to the prototype, and thus have
      the correct sizes.  If we specify CInt in the FFI call, it should correspond
      to the C int, and not just be Word sized, when it's only half the size.
      
      This does change the expected output of T16402 but the new result is no
      less correct as it eliminates the narrowing (instead of the `and` as was
      previously done).
      
      Bumps the array, bytestring, text, and binary submodules.
      Co-Authored-By: Ben Gamari's avatarBen Gamari <ben@well-typed.com>
      
      Metric Increase:
          T13701
          T14697
      be5d74ca
  3. 21 Nov, 2020 3 commits
    • Sylvain Henry's avatar
      Don't initialize plugins in the Core2Core pipeline · 72f2257c
      Sylvain Henry authored
      Some plugins can be added via TH (cf addCorePlugin). Initialize them in
      the driver instead of in the Core2Core pipeline.
      72f2257c
    • Sylvain Henry's avatar
      Move Plugins into HscEnv (#17957) · ecfd0278
      Sylvain Henry authored
      Loaded plugins have nothing to do in DynFlags so this patch moves them
      into HscEnv (session state).
      
      "DynFlags plugins" become "Driver plugins" to still be able to register
      static plugins.
      
      Bump haddock submodule
      ecfd0278
    • Ben Gamari's avatar
      Introduce -fprof-callers flag · 53ad67ea
      Ben Gamari authored
      This introducing a new compiler flag to provide a convenient way to
      introduce profiler cost-centers on all occurrences of the named
      identifier.
      
      Closes #18566.
      53ad67ea
  4. 20 Nov, 2020 1 commit
    • Sebastian Graf's avatar
      Demand: Interleave usage and strictness demands (#18903) · 0aec78b6
      Sebastian Graf authored
      As outlined in #18903, interleaving usage and strictness demands not
      only means a more compact demand representation, but also allows us to
      express demands that we weren't easily able to express before.
      
      Call demands are *relative* in the sense that a call demand `Cn(cd)`
      on `g` says "`g` is called `n` times. *Whenever `g` is called*, the
      result is used according to `cd`". Example from #18903:
      
      ```hs
      h :: Int -> Int
      h m =
        let g :: Int -> (Int,Int)
            g 1 = (m, 0)
            g n = (2 * n, 2 `div` n)
            {-# NOINLINE g #-}
        in case m of
          1 -> 0
          2 -> snd (g m)
          _ -> uncurry (+) (g m)
      ```
      
      Without the interleaved representation, we would just get `L` for the
      strictness demand on `g`. Now we are able to express that whenever
      `g` is called, its second component is used strictly in denoting `g`
      by `1C1(P(1P(U),SP(U)))`. This would allow Nested CPR to unbox the
      division, for example.
      
      Fixes #18903.
      While fixing regressions, I also discovered and fixed #18957.
      
      Metric Decrease:
          T13253-spj
      0aec78b6
  5. 15 Nov, 2020 2 commits
    • Ryan Scott's avatar
      Use tcSplitForAllInvisTyVars (not tcSplitForAllTyVars) in more places · 645444af
      Ryan Scott authored
      The use of `tcSplitForAllTyVars` in `tcDataFamInstHeader` was the immediate
      cause of #18939, and replacing it with a new `tcSplitForAllInvisTyVars`
      function (which behaves like `tcSplitForAllTyVars` but only splits invisible
      type variables) fixes the issue. However, this led me to realize that _most_
      uses of `tcSplitForAllTyVars` in GHC really ought to be
      `tcSplitForAllInvisTyVars` instead. While I was in town, I opted to replace
      most uses of `tcSplitForAllTys` with `tcSplitForAllTysInvis` to reduce the
      likelihood of such bugs in the future.
      
      I say "most uses" above since there is one notable place where we _do_ want
      to use `tcSplitForAllTyVars`: in `GHC.Tc.Validity.forAllTyErr`, which produces
      the "`Illegal polymorphic type`" error message if you try to use a higher-rank
      `forall` without having `RankNTypes` enabled. Here, we really do want to split
      all `forall`s, not just invisible ones, or we run the risk of giving an
      inaccurate error message in the newly added `T18939_Fail` test case.
      
      I debated at some length whether I wanted to name the new function
      `tcSplitForAllInvisTyVars` or `tcSplitForAllTyVarsInvisible`, but in the end,
      I decided that I liked the former better. For consistency's sake, I opted to
      rename the existing `splitPiTysInvisible` and `splitPiTysInvisibleN` functions
      to `splitInvisPiTys` and `splitPiTysInvisN`, respectively, so that they use the
      same naming convention. As a consequence, this ended up requiring a `haddock`
      submodule bump.
      
      Fixes #18939.
      645444af
    • Ryan Scott's avatar
      Name (tc)SplitForAll- functions more consistently · d61adb3d
      Ryan Scott authored
      There is a zoo of `splitForAll-` functions in `GHC.Core.Type` (as well as
      `tcSplitForAll-` functions in `GHC.Tc.Utils.TcType`) that all do very similar
      things, but vary in the particular form of type variable that they return. To
      make things worse, the names of these functions are often quite misleading.
      Some particularly egregious examples:
      
      * `splitForAllTys` returns `TyCoVar`s, but `splitSomeForAllTys` returns
        `VarBndr`s.
      * `splitSomeForAllTys` returns `VarBndr`s, but `tcSplitSomeForAllTys` returns
        `TyVar`s.
      * `splitForAllTys` returns `TyCoVar`s, but `splitForAllTysInvis` returns
        `InvisTVBinder`s. (This in particular arose in the context of #18939, and
        this finally motivated me to bite the bullet and improve the status quo
        vis-à-vis how we name these functions.)
      
      In an attempt to bring some sanity to how these functions are named, I have
      opted to rename most of these functions en masse to use consistent suffixes
      that describe the particular form of type variable that each function returns.
      In concrete terms, this amounts to:
      
      * Functions that return a `TyVar` now use the suffix `-TyVar`.
        This caused the following functions to be renamed:
        * `splitTyVarForAllTys` -> `splitForAllTyVars`
        * `splitForAllTy_ty_maybe` -> `splitForAllTyVar_maybe`
        * `tcSplitForAllTys` -> `tcSplitForAllTyVars`
        * `tcSplitSomeForAllTys` -> `tcSplitSomeForAllTyVars`
      * Functions that return a `CoVar` now use the suffix `-CoVar`.
        This caused the following functions to be renamed:
        * `splitForAllTy_co_maybe` -> `splitForAllCoVar_maybe`
      * Functions that return a `TyCoVar` now use the suffix `-TyCoVar`.
        This caused the following functions to be renamed:
        * `splitForAllTy` -> `splitForAllTyCoVar`
        * `splitForAllTys` -> `splitForAllTyCoVars`
        * `splitForAllTys'` -> `splitForAllTyCoVars'`
        * `splitForAllTy_maybe` -> `splitForAllTyCoVar_maybe`
      * Functions that return a `VarBndr` now use the suffix corresponding to the
        most relevant type synonym. This caused the following functions to be renamed:
        * `splitForAllVarBndrs` -> `splitForAllTyCoVarBinders`
        * `splitForAllTysInvis` -> `splitForAllInvisTVBinders`
        * `splitForAllTysReq` -> `splitForAllReqTVBinders`
        * `splitSomeForAllTys` -> `splitSomeForAllTyCoVarBndrs`
        * `tcSplitForAllVarBndrs` -> `tcSplitForAllTyVarBinders`
        * `tcSplitForAllTysInvis` -> `tcSplitForAllInvisTVBinders`
        * `tcSplitForAllTysReq` -> `tcSplitForAllReqTVBinders`
        * `tcSplitForAllTy_maybe` -> `tcSplitForAllTyVarBinder_maybe`
      
      Note that I left the following functions alone:
      
      * Functions that split apart things besides `ForAllTy`s, such as `splitFunTys`
        or `splitPiTys`. Thankfully, there are far fewer of these functions than
        there are functions that split apart `ForAllTy`s, so there isn't much of a
        pressing need to apply the new naming convention elsewhere.
      * Functions that split apart `ForAllCo`s in `Coercion`s, such as
        `GHC.Core.Coercion.splitForAllCo_maybe`. We could theoretically apply the new
        naming convention here, but then we'd have to figure out how to disambiguate
        `Type`-splitting functions from `Coercion`-splitting functions. Ultimately,
        the `Coercion`-splitting functions aren't used nearly as much as the
        `Type`-splitting functions, so I decided to leave the former alone.
      
      This is purely refactoring and should cause no change in behavior.
      d61adb3d
  6. 13 Nov, 2020 2 commits
    • Sebastian Graf's avatar
      Arity: Emit "Exciting arity" warning only after second iteration (#18937) · 197d59fa
      Sebastian Graf authored
      See Note [Exciting arity] why we emit the warning at all and why we only
      do after the second iteration now.
      
      Fixes #18937.
      197d59fa
    • Sebastian Graf's avatar
      Arity: Rework `ArityType` to fix monotonicity (#18870) · 63fa3997
      Sebastian Graf authored
      As we found out in #18870, `andArityType` is not monotone, with
      potentially severe consequences for termination of fixed-point
      iteration. That showed in an abundance of "Exciting arity" DEBUG
      messages that are emitted whenever we do more than one step in
      fixed-point iteration.
      
      The solution necessitates also recording `OneShotInfo` info for
      `ABot` arity type. Thus we get the following definition for `ArityType`:
      
      ```
      data ArityType = AT [OneShotInfo] Divergence
      ```
      
      The majority of changes in this patch are the result of refactoring use
      sites of `ArityType` to match the new definition.
      
      The regression test `T18870` asserts that we indeed don't emit any DEBUG
      output anymore for a function where we previously would have.
      Similarly, there's a regression test `T18937` for #18937, which we
      expect to be broken for now.
      
      Fixes #18870.
      63fa3997
  7. 06 Nov, 2020 1 commit
    • Ryan Scott's avatar
      Replace HsImplicitBndrs with HsOuterTyVarBndrs · e07e383a
      Ryan Scott authored
      This refactors the GHC AST to remove `HsImplicitBndrs` and replace it with
      `HsOuterTyVarBndrs`, a type which records whether the outermost quantification
      in a type is explicit (i.e., with an outermost, invisible `forall`) or
      implicit. As a result of this refactoring, it is now evident in the AST where
      the `forall`-or-nothing rule applies: it's all the places that use
      `HsOuterTyVarBndrs`. See the revamped `Note [forall-or-nothing rule]` in
      `GHC.Hs.Type` (previously in `GHC.Rename.HsType`).
      
      Moreover, the places where `ScopedTypeVariables` brings lexically scoped type
      variables into scope are a subset of the places that adhere to the
      `forall`-or-nothing rule, so this also makes places that interact with
      `ScopedTypeVariables` easier to find. See the revamped
      `Note [Lexically scoped type variables]` in `GHC.Hs.Type` (previously in
      `GHC.Tc.Gen.Sig`).
      
      `HsOuterTyVarBndrs` are used in type signatures (see `HsOuterSigTyVarBndrs`)
      and type family equations (see `HsOuterFamEqnTyVarBndrs`). The main difference
      between the former and the latter is that the former cares about specificity
      but the latter does not.
      
      There are a number of knock-on consequences:
      
      * There is now a dedicated `HsSigType` type, which is the combination of
        `HsOuterSigTyVarBndrs` and `HsType`. `LHsSigType` is now an alias for an
        `XRec` of `HsSigType`.
      * Working out the details led us to a substantial refactoring of
        the handling of explicit (user-written) and implicit type-variable
        bindings in `GHC.Tc.Gen.HsType`.
      
        Instead of a confusing family of higher order functions, we now
        have a local data type, `SkolemInfo`, that controls how these
        binders are kind-checked.
      
        It remains very fiddly, not fully satisfying. But it's better
        than it was.
      
      Fixes #16762. Bumps the Haddock submodule.
      Co-authored-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Co-authored-by: Richard Eisenberg's avatarRichard Eisenberg <rae@richarde.dev>
      Co-authored-by: wz1000's avatarZubin Duggal <zubin@cmi.ac.in>
      e07e383a
  8. 03 Nov, 2020 2 commits
    • Sylvain Henry's avatar
      Constant-folding: don't pass through GHC's Int/Word (fix #11704) · 37f0434d
      Sylvain Henry authored
      Constant-folding rules for integerToWord/integerToInt were performing
      the following coercions at compilation time:
      
          integerToWord: target's Integer -> ghc's Word -> target's Word
          integerToInt : target's Integer -> ghc's Int -> target's Int
      
      1) It was wrong for cross-compilers when GHC's word size is smaller than
         the target one. This patch avoids passing through GHC's word-sized
         types:
      
          integerToWord: target's Integer -> ghc's Integer -> target's Word
          integerToInt : target's Integer -> ghc's Integer -> target's Int
      
      2) Additionally we didn't wrap the target word/int literal to make it
         fit into the target's range! This broke the invariant of literals
         only containing values in range.
      
         The existing code is wrong only with a 64-bit cross-compiling GHC,
         targeting a 32-bit platform, and performing constant folding on a
         literal that doesn't fit in a 32-bit word. If GHC was built with
         DEBUG, the assertion in GHC.Types.Literal.mkLitWord would fail.
         Otherwise the bad transformation would go unnoticed.
      37f0434d
    • Ryan Scott's avatar
      Display results of GHC.Core.Lint.lint* functions consistently · bfb1e272
      Ryan Scott authored
      Previously, the functions in `GHC.Core.Lint` used a patchwork of
      different ways to display Core Lint errors:
      
      * `lintPassResult` (which is the source of most Core Lint errors) renders
        Core Lint errors with a distinctive banner (e.g.,
        `*** Core Lint errors : in result of ... ***`) that sets them apart
        from ordinary GHC error messages.
      * `lintAxioms`, in contrast, uses a completely different code path that
        displays Core Lint errors in a rather confusing manner. For example,
        the program in #18770 would give these results:
      
        ```
        Bug.hs:1:1: error:
            Bug.hs:12:1: warning:
                Non-*-like kind when *-like expected: RuntimeRep
                when checking the body of forall: 'TupleRep '[r]
                In the coercion axiom Bug.N:T :: []. Bug.T ~_R Any
                Substitution: [TCvSubst
                                 In scope: InScope {r}
                                 Type env: [axl :-> r]
                                 Co env: []]
          |
        1 | {-# LANGUAGE DataKinds #-}
          | ^
        ```
      * Further digging reveals that `GHC.IfaceToCore` displays Core Lint
        errors for iface unfoldings as though they were a GHC panic. See, for
        example, this excerpt from #17723:
      
        ```
        ghc: panic! (the 'impossible' happened)
          (GHC version 8.8.2 for x86_64-unknown-linux):
                Iface Lint failure
          In interface for Lib
          ...
        ```
      
      This patch makes all of these code paths display Core Lint errors and
      warnings consistently. I decided to adopt the conventions that
      `lintPassResult` currently uses, as they appear to have been around the
      longest (and look the best, in my subjective opinion). We now use the
      `displayLintResult` function for all three scenarios mentioned above.
      For example, here is what the Core Lint error for the program in #18770 looks
      like after this patch:
      
      ```
      [1 of 1] Compiling Bug              ( Bug.hs, Bug.o )
      *** Core Lint errors : in result of TcGblEnv axioms ***
      Bug.hs:12:1: warning:
          Non-*-like kind when *-like expected: RuntimeRep
          when checking the body of forall: 'TupleRep '[r_axn]
          In the coercion axiom N:T :: []. T ~_R Any
          Substitution: [TCvSubst
                           In scope: InScope {r_axn}
                           Type env: [axn :-> r_axn]
                           Co env: []]
      *** Offending Program ***
      axiom N:T :: T = Any -- Defined at Bug.hs:12:1
      *** End of Offense ***
      
      <no location info>: error:
      Compilation had errors
      ```
      
      Fixes #18770.
      bfb1e272
  9. 01 Nov, 2020 1 commit
  10. 31 Oct, 2020 3 commits
    • Sylvain Henry's avatar
      Simplify constant-folding (#18032) · 730ef38f
      Sylvain Henry authored
      See #18032 for the details.
      
      * Use `Lit (LitNumber _ i)` instead of `isLitValue_maybe` which does
        more work but that is not needed for constant-folding
      * Don't export `GHC.Types.Literal.isLitValue_maybe`
      * Kill `GHC.Types.Literal.isLitValue` which isn't used
      730ef38f
    • Sylvain Henry's avatar
      Refactor numeric constant folding rules · a98593f0
      Sylvain Henry authored
      Avoid the use of global pattern synonyms.
      
      1) I think it's going to be helpful to implement constant folding for
         other numeric types, especially Natural which doesn't have a wrapping
         behavior. We'll have to refactor these rules even more so we'd better
         make them less cryptic.
      
      2) It should also be slightly faster because global pattern synonyms
         matched operations for every numeric types instead of the current one:
         e.g., ":**:" pattern was matching multiplication for both Int# and
         Word# types. As we will probably want to implement constant folding
         for other numeric types (Int8#, Int16#, etc.), it is more efficient
         to only match primops for a given type as we do now.
      a98593f0
    • Ryan Scott's avatar
      Make typechecker equality consider visibility in ForAllTys · 57c3db96
      Ryan Scott authored
      Previously, `can_eq_nc'` would equate `ForAllTy`s regardless of their
      `ArgFlag`, including `forall i -> i -> Type` and `forall i. i -> Type`! To fix
      this, `can_eq_nc'` now uses the `sameVis` function to first check if the
      `ArgFlag`s are equal modulo specificity. I have also updated `tcEqType`'s
      implementation to match this behavior. For more explanation on the "modulo
      specificity" part, see the new `Note [ForAllTy and typechecker equality]`
      in `GHC.Tc.Solver.Canonical`.
      
      While I was in town, I fixed some related documentation issues:
      
      * I added `Note [Typechecker equality]` to `GHC.Tc.Utils.TcType` to describe
        what exactly distinguishes `can_eq_nc'` and `tcEqType` (which implement
        typechecker equality) from `eqType` (which implements definitional equality,
        which does not care about the `ArgFlags` of `ForAllTy`s at all).
      * The User's Guide had some outdated prose on the specified/inferred
        distinction being different for types and kinds, a holdover from #15079. This
        is no longer the case on today's GHC, so I removed this prose, added some new
        prose to take its place, and added a regression test for the programs in
        #15079.
      * The User's Guide had some _more_ outdated prose on inferred type variables
        not being allowed in `default` type signatures for class methods, which is no
        longer true as of the resolution of #18432.
      * The related `Note [Deferred Unification]` was being referenced as
        `Note [Deferred unification]` elsewhere, which made it harder to `grep`
        for. I decided to change the name of the Note to `Deferred unification`
        for consistency with the capitalization style used for most other Notes.
      
      Fixes #18863.
      57c3db96
  11. 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
  12. 29 Oct, 2020 1 commit
    • Sylvain Henry's avatar
      Split GHC.Driver.Types · 0e9f6def
      Sylvain Henry authored
      I was working on making DynFlags stateless (#17957), especially by
      storing loaded plugins into HscEnv instead of DynFlags. It turned out to
      be complicated because HscEnv is in GHC.Driver.Types but LoadedPlugin
      isn't: it is in GHC.Driver.Plugins which depends on GHC.Driver.Types. I
      didn't feel like introducing yet another hs-boot file to break the loop.
      
      Additionally I remember that while we introduced the module hierarchy
      (#13009) we talked about splitting GHC.Driver.Types because it contained
      various unrelated types and functions, but we never executed. I didn't
      feel like making GHC.Driver.Types bigger with more unrelated Plugins
      related types, so finally I bit the bullet and split GHC.Driver.Types.
      
      As a consequence this patch moves a lot of things. I've tried to put
      them into appropriate modules but nothing is set in stone.
      
      Several other things moved to avoid loops.
      
      * Removed Binary instances from GHC.Utils.Binary for random compiler
        things
      * Moved Typeable Binary instances into GHC.Utils.Binary.Typeable: they
        import a lot of things that users of GHC.Utils.Binary don't want to
        depend on.
      * put everything related to Units/Modules under GHC.Unit:
        GHC.Unit.Finder, GHC.Unit.Module.{ModGuts,ModIface,Deps,etc.}
      * Created several modules under GHC.Types: GHC.Types.Fixity, SourceText,
        etc.
      * Split GHC.Utils.Error (into GHC.Types.Error)
      * Finally removed GHC.Driver.Types
      
      Note that this patch doesn't put loaded plugins into HscEnv. It's left
      for another patch.
      
      Bump haddock submodule
      0e9f6def
  13. 27 Oct, 2020 2 commits
    • Sebastian Graf's avatar
      DmdAnal: Kill `is_thunk` case in `splitFV` · 28f98b01
      Sebastian Graf authored
      The `splitFV` function implements the highly dubious hack
      described in `Note [Lazy und unleashable free variables]` in
      GHC.Core.Opt.DmdAnal. It arranges it so that demand signatures only
      carry strictness info on free variables. Usage info is released through
      other means, see the Note. It's purely for analysis performance reasons.
      
      It turns out that `splitFV` has a quite involved case for thunks that
      produces slightly different usage signatures and it's not clear why we
      need it: `splitFV` is only relevant in the LetDown case and the only
      time we call it on thunks is for top-level or local recursive thunks.
      
      Since usage signatures of top-level thunks can only reference other
      top-level bindings and we completely discard demand info we have on
      top-level things (see the lack of `setIdDemandInfo` in
      `dmdAnalTopBind`), the `is_thunk` case is completely irrelevant here.
      
      For local, recursive thunks, the added benefit of the `is_thunk` test
      is marginal: We get used-multiple-times in some cases where previously
      we had used-once if a recursive thunk has multiple call sites. It's
      very unlikely and not a case to optimise for.
      
      So we kill the `is_thunk` case and inline `splitFV` at its call site,
      exposing `isWeakDmd` from `GHC.Types.Demand` instead.
      
      The NoFib summary supports this decision:
      
      ```
                  Min           0.0%     -0.0%
                  Max           0.0%     +0.0%
       Geometric Mean          -0.0%     -0.0%
      ```
      28f98b01
    • Simon Peyton Jones's avatar
      Fix two constraint solving problems · 0b3d23af
      Simon Peyton Jones authored
      This patch fixes two problems in the constraint solver.
      
      * An actual bug #18555: we were floating out a constraint to eagerly,
        and that was ultimately fatal.  It's explained in
        Note [Do not float blocked constraints] in GHC.Core.Constraint.
      
        This is all very delicate, but it's all going to become irrelevant
        when we stop floating constraints (#17656).
      
      * A major performance infelicity in the flattener.  When flattening
        (ty |> co) we *never* generated Refl, even when there was nothing
        at all to do.  Result: we would gratuitously rewrite the constraint
        to exactly the same thing, wasting work.  Described in #18413, and
        came up again in #18855.
      
        Solution: exploit the special case by calling the new function
        castCoercionKind1.  See Note [castCoercionKind1] in
        GHC.Core.Coercion
      0b3d23af
  14. 20 Oct, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Minor comments, update linear types docs · 6c7a5c0c
      Krzysztof Gogolewski authored
      - Update comments: placeHolderTypeTc no longer exists
        "another level check problem" was a temporary comment from linear types
      - Use Mult type synonym (reported in #18676)
      - Mention multiplicity-polymorphic fields in linear types docs
      6c7a5c0c
  15. 18 Oct, 2020 2 commits
    • Sebastian Graf's avatar
      Arity: Record arity types for non-recursive lets · 6b3eb06a
      Sebastian Graf authored
      In #18793, we saw a compelling example which requires us to look at
      non-recursive let-bindings during arity analysis and unleash their arity
      types at use sites.
      
      After the refactoring in the previous patch, the needed change is quite
      simple and very local to `arityType`'s defn for non-recurisve `Let`.
      
      Apart from that, we had to get rid of the second item of
      `Note [Dealing with bottoms]`, which was entirely a safety measure and
      hindered optimistic fixed-point iteration.
      
      Fixes #18793.
      
      The following metric increases are all caused by this commit and a
      result of the fact that we just do more work now:
      
      Metric Increase:
          T3294
          T12545
          T12707
      6b3eb06a
    • Sebastian Graf's avatar
      Arity: Refactor fixed-point iteration in GHC.Core.Opt.Arity · 7eb46a09
      Sebastian Graf authored
      Arity analysis used to propagate optimistic arity types during
      fixed-point interation through the `ArityEnv`'s `ae_cheap_fun` field,
      which is like `GHC.Core.Utils.exprIsCheap`, but also considers the
      current iteration's optimistic arity, for the binder in question only.
      
      In #18793, we have seen that this is a problematic design, because it
      doesn't allow us to look through PAP bindings of that binder.
      
      Hence this patch refactors to a more traditional form with an explicit
      signature environment, in which we record the optimistic `ArityType` of
      the binder in question (and at the moment is the *only* binder that is
      recorded in the arity environment).
      7eb46a09
  16. 14 Oct, 2020 1 commit
    • Simon Peyton Jones's avatar
      Fix some missed opportunities for preInlineUnconditionally · 15d2340c
      Simon Peyton Jones authored
      There are two signficant changes here:
      
      * Ticket #18815 showed that we were missing some opportunities for
        preInlineUnconditionally.  The one-line fix is in the code for
        GHC.Core.Opt.Simplify.Utils.preInlineUnconditionally, which now
        switches off only for INLINE pragmas.  I expanded
        Note [Stable unfoldings and preInlineUnconditionally] to explain.
      
      * When doing this I discovered a way in which preInlineUnconditionally
        was occasionally /too/ eager.  It's all explained in
        Note [Occurrences in stable unfoldings] in GHC.Core.Opt.OccurAnal,
        and the one-line change adding markAllMany to occAnalUnfolding.
      
      I also got confused about what NoUserInline meant, so I've renamed
      it to NoUserInlinePrag, and changed its pretty-printing slightly.
      That led to soem error messate wibbling, and touches quite a few
      files, but there is no change in functionality.
      
      I did a nofib run.  As expected, no significant changes.
      
              Program           Size    Allocs
      ----------------------------------------
               sphere          -0.0%     -0.4%
      ----------------------------------------
                  Min          -0.0%     -0.4%
                  Max          -0.0%     +0.0%
       Geometric Mean          -0.0%     -0.0%
      
      I'm allowing a max-residency increase for T10370, which seems
      very irreproducible. (See comments on !4241.)  There is always
      sampling error for max-residency measurements; and in any case
      the change shows up on some platforms but not others.
      
      Metric Increase:
          T10370
      15d2340c
  17. 13 Oct, 2020 1 commit
    • Rinat Striungis's avatar
      Unification of Nat and Naturals · 8f4f5794
      Rinat Striungis authored
      This commit removes the separate kind 'Nat' and enables promotion
      of type 'Natural' for using as type literal.
      It partially solves #10776
      
      Now the following code will be successfully typechecked:
          data C = MkC Natural
          type CC = MkC 1
      
      Before this change we had to create the separate type for promotion
          data C = MkC Natural
          data CP = MkCP Nat
          type CC = MkCP 1
      
      But CP is uninhabited in terms.
      
      For backward compatibility type synonym `Nat` has been made:
          type Nat = Natural
      
      The user's documentation and tests have been updated.
      The haddock submodule also have been updated.
      8f4f5794
  18. 12 Oct, 2020 1 commit
  19. 10 Oct, 2020 1 commit
  20. 09 Oct, 2020 4 commits
    • Sylvain Henry's avatar
      Cache HomeUnit in HscEnv (#17957) · 6a243e9d
      Sylvain Henry authored
      Instead of recreating the HomeUnit from the DynFlags every time we need
      it, we store it in the HscEnv.
      6a243e9d
    • 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
    • Simon Peyton Jones's avatar
      Fix desugaring of record updates on data families · bfdccac6
      Simon Peyton Jones authored
      This fixes a long-standing bug in the desugaring of record
      updates for data families, when the latter involves a GADT. It's
      all explained in Note [Update for GADTs] in GHC.HsToCore.Expr.
      
      Building the correct cast is surprisingly tricky, as that Note
      explains.
      
      Fixes #18809.  The test case (in indexed-types/should_compile/T18809)
      contains several examples that exercise the dark corners.
      bfdccac6
    • Sylvain Henry's avatar
      Bignum: match on small Integer/Natural · 12191a99
      Sylvain Henry authored
      Previously we only matched on *variables* whose unfoldings were a ConApp
      of the form `IS lit#` or `NS lit##`. But we forgot to match on the
      ConApp directly... As a consequence, constant folding only worked after
      the FloatOut pass which creates bindings for most sub-expressions. With
      this patch, matching on bignums works even with -O0 (see bignumMatch
      test).
      12191a99
  21. 07 Oct, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Misc cleanup · e91ddddd
      Krzysztof Gogolewski authored
      * Include funTyCon in exposedPrimTyCons.
        Every single place using exposedPrimTyCons was adding funTyCon
        manually.
      * Remove unused synTyConResKind and ieLWrappedName
      * Add recordSelectorTyCon_maybe
      * In exprType, panic instead of giving a trace message and dummy output.
        This prevents #18767 reoccurring.
      * Fix compilation error in fragile concprog001 test (part of #18732)
      e91ddddd
  22. 05 Oct, 2020 1 commit
    • Sebastian Graf's avatar
      Inline `integerDecodeDouble#` and constant-fold `decodeDouble_Int64#` instead · bc5de347
      Sebastian Graf authored
      Currently, `integerDecodeDouble#` is known-key so that it can be
      recognised in constant folding. But that is very brittle and doesn't
      survive worker/wrapper, which we even do for
      `NOINLINE` things since #13143.
      Also it is a trade-off: The implementation of `integerDecodeDouble#`
      allocates an `Integer` box that never cancels aways if we don't inline
      it.
      
      Hence we recognise the `decodeDouble_Int64#` primop instead in constant
      folding, so that we can inline `integerDecodeDouble#`. As a result,
      `integerDecodeDouble#` no longer needs to be known-key.
      
      While doing so, I realised that we don't constant-fold
      `decodeFloat_Int#` either, so I also added a RULE for it.
      
      `integerDecodeDouble` is dead, so I deleted it.
      
      Part of #18092. This improves the 32-bit `realToFrac`/`toRational`:
      
      Metric Decrease:
          T10359
      bc5de347
  23. 02 Oct, 2020 1 commit
  24. 01 Oct, 2020 2 commits
    • Sebastian Graf's avatar
      Don't attach CPR signatures to NOINLINE data structures (#18154) · e3655f81
      Sebastian Graf authored
      Because the generated `KindRep`s don't have an unfolding, !3230 did not
      actually stop to compute, attach and serialise unnecessary CPR
      signatures for them. As already said in
      `Note [CPR for data structures]`, that leads to bloated interface
      files which is ultimately quadratic for Nested CPR.
      
      So we don't attach any CPR signature to bindings that
      
        * Are not thunks (because thunks are not in WHNF)
        * Have arity 0 (which means the top-level constructor is not a lambda)
      
      If the data structure has an unfolding, we continue to look through it.
      If not (as is the case for `KindRep`s), we look at the unchanged CPR
      signature and see `topCprType`, as expected.
      e3655f81
    • Sylvain Henry's avatar
  25. 30 Sep, 2020 1 commit
  26. 29 Sep, 2020 1 commit