1. 22 Nov, 2018 1 commit
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4881
      13bb4bf4
  2. 24 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor the treatment of predicate types · 0faf7fd3
      Simon Peyton Jones authored
      Trac #15648 showed that GHC was a bit confused about the
      difference between the types for
      
      * Predicates
      * Coercions
      * Evidence (in the typechecker constraint solver)
      
      This patch cleans it up. See especially Type.hs
      Note [Types for coercions, predicates, and evidence]
      
      Particular changes
      
      * Coercion types (a ~# b) and (a ~#R b) are not predicate types
        (so isPredTy reports False for them) and are not implicitly
        instantiated by the type checker.  This is a real change, but
        it consistently reflects that fact that (~#) and (~R#) really
        are different from predicates.
      
      * isCoercionType is renamed to isCoVarType
      
      * During type inference, simplifyInfer, we do /not/ want to infer
        a constraint (a ~# b), because that is no longer a predicate type.
        So we 'lift' it to (a ~ b). See TcType
        Note [Lift equality constaints when quantifying]
      
      * During type inference for pattern synonyms, we need to 'lift'
        provided constraints of type (a ~# b) to (a ~ b).  See
        Note [Equality evidence in pattern synonyms] in PatSyn
      
      * But what about (forall a. Eq a => a ~# b)? Is that a
        predicate type?  No -- it does not have kind Constraint.
        Is it an evidence type?  Perhaps, but awkwardly so.
      
        In the end I decided NOT to make it an evidence type,
        and to ensure the the type inference engine never
        meets it.  This made me /simplify/ the code in
        TcCanonical.makeSuperClasses; see TcCanonical
        Note [Equality superclasses in quantified constraints]
      
        Instead I moved the special treatment for primitive
        equality to TcInteract.doTopReactOther.  See TcInteract
        Note [Looking up primitive equalities in quantified constraints]
      
        Also see Note [Evidence for quantified constraints] in Type.
      
        All this means I can have
           isEvVarType ty = isCoVarType ty || isPredTy ty
        which is nice.
      
      All in all, rather a lot of work for a small refactoring,
      but I think it's a real improvement.
      0faf7fd3
  3. 15 Sep, 2018 1 commit
    • Ningning Xie's avatar
      Coercion Quantification · ea5ade34
      Ningning Xie authored
      This patch corresponds to #15497.
      
      According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2,
       we would like to have coercion quantifications back. This will
      allow us to migrate (~#) to be homogeneous, instead of its current
      heterogeneous definition. This patch is (lots of) plumbing only. There
      should be no user-visible effects.
      
      An overview of changes:
      
      - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables,
      but only in *Core*. All relevant functions are updated accordingly.
      - Small changes that should be irrelevant to the main task:
          1. removed dead code `mkTransAppCo` in Coercion
          2. removed out-dated Note Computing a coercion kind and
             roles in Coercion
          3. Added `Eq4` in Note Respecting definitional equality in
             TyCoRep, and updated `mkCastTy` accordingly.
          4. Various updates and corrections of notes and typos.
      - Haddock submodule needs to be changed too.
      
      Acknowledgments:
      This work was completed mostly during Ningning Xie's Google Summer
      of Code, sponsored by Google. It was advised by Richard Eisenberg,
      supported by NSF grant 1704041.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar
      
      Subscribers: RyanGlScott, monoidal, rwbarton, carter
      
      GHC Trac Issues: #15497
      
      Differential Revision: https://phabricator.haskell.org/D5054
      ea5ade34
  4. 13 Sep, 2018 1 commit
    • Simon Peyton Jones's avatar
      Allow (~) in the head of a quantified constraints · bd76875a
      Simon Peyton Jones authored
      Since the introduction of quantified constraints, GHC has rejected
      a quantified constraint with (~) in the head, thus
        f :: (forall a. blah => a ~ ty) => stuff
      
      I am frankly dubious that this is ever useful.  But /is/ necessary for
      Coercible (representation equality version of (~)) and it does no harm
      to allow it for (~) as well.  Plus, our users are asking for it
      (Trac #15359, #15625).
      
      It was really only excluded by accident, so
      this patch lifts the restriction. See TcCanonical
      Note [Equality superclasses in quantified constraints]
      
      There are a number of wrinkles:
      
      * If the context of the quantified constraint is empty, we
        can get trouble when we get down to unboxed equality (a ~# b)
        or (a ~R# b), as Trac #15625 showed. This is even more of
        a corner case, but it produced an outright crash, so I elaborated
        the superclass machinery in TcCanonical.makeStrictSuperClasses
        to add a void argument in this case.  See
        Note [Equality superclasses in quantified constraints]
      
      * The restriction on (~) was in TcValidity.checkValidInstHead.
        In lifting the restriction I discovered an old special case for
        (~), namely
            | clas_nm `elem` [ heqTyConName, eqTyConName]
            , nameModule clas_nm /= this_mod
        This was (solely) to support the strange instance
            instance a ~~ b => a ~ b
        in Data.Type.Equality. But happily that is no longer
        with us, since
           commit f265008f
           Refactor (~) to reduce the suerpclass stack
        So I removed the special case.
      
      * I found that the Core invariants on when we could have
             co = <expr>
        were entirely not written down. (Getting this wrong ws
        the proximate source of the crash in Trac #15625.  So
      
        - Documented them better in CoreSyn
            Note [CoreSyn type and coercion invariant],
        - Modified CoreOpt and CoreLint to match
        - Modified CoreUtils.bindNonRec to match
        - Made MkCore.mkCoreLet use bindNonRec, rather
          than duplicate its logic
        - Made Simplify.rebuildCase case-to-let respect
            Note [CoreSyn type and coercion invariant],
      bd76875a
  5. 21 Aug, 2018 2 commits
    • Andreas Klebinger's avatar
      Replace most occurences of foldl with foldl'. · 09c1d5af
      Andreas Klebinger authored
      This patch adds foldl' to GhcPrelude and changes must occurences
      of foldl to foldl'. This leads to better performance especially
      for quick builds where GHC does not perform strictness analysis.
      
      It does change strictness behaviour when we use foldl' to turn
      a argument list into function applications. But this is only a
      drawback if code looks ONLY at the last argument but not at the first.
      And as the benchmarks show leads to fewer allocations in practice
      at O2.
      
      Compiler performance for Nofib:
      
      O2 Allocations:
              -1 s.d.                -----            -0.0%
              +1 s.d.                -----            -0.0%
              Average                -----            -0.0%
      
      O2 Compile Time:
              -1 s.d.                -----            -2.8%
              +1 s.d.                -----            +1.3%
              Average                -----            -0.8%
      
      O0 Allocations:
              -1 s.d.                -----            -0.2%
              +1 s.d.                -----          ...
      09c1d5af
    • Simon Peyton Jones's avatar
      Set strictness correctly for JoinIds · ce6ce788
      Simon Peyton Jones authored
      We were failing to keep correct strictness info when eta-expanding
      join points; Trac #15517.   The situation was something like
      
        \q v eta ->
           let j x = error "blah
               -- STR Lx   bottoming!
           in case y of
                 A -> j x eta
                 B -> blah
                 C -> j x eta
      
      So we spot j as a join point and eta-expand it.  But we must
      also adjust the stricness info, else it vlaimes to bottom after
      one arg is applied but now it has become two.
      
      I fixed this in two places:
      
       - In CoreOpt.joinPointBinding_maybe, adjust strictness info
      
       - In SimplUtils.tryEtaExpandRhs, return consistent values
         for arity and bottom-ness
      ce6ce788
  6. 23 Jul, 2018 1 commit
    • Richard Eisenberg's avatar
      Fix some casts. · af624071
      Richard Eisenberg authored
      This fixes #15346, and is a team effort between Ryan Scott and
      myself (mostly Ryan). We discovered two errors related to FC's
      "push" rules, one in the TPush rule (as implemented in pushCoTyArg)
      and one in KPush rule (it shows up in liftCoSubstVarBndr).
      
      The solution: do what the paper says, instead of whatever random
      thoughts popped into my head as I was actually implementing.
      
      Also fixes #15419, which is actually the same underlying problem.
      
      Test case: dependent/should_compile/T{15346,15419}.
      af624071
  7. 10 Jul, 2018 1 commit
    • Ningning Xie's avatar
      Refactor coercion rule · 55a3f855
      Ningning Xie authored
      Summary:
      The patch is an attempt on #15192.
      
      It defines a new coercion rule
      
      ```
       | GRefl Role Type MCoercion
      ```
      
      which correspondes to the typing rule
      
      ```
           t1 : k1
        ------------------------------------
        GRefl r t1 MRefl: t1 ~r t1
      
           t1 : k1       co :: k1 ~ k2
        ------------------------------------
        GRefl r t1 (MCo co) : t1 ~r t1 |> co
      ```
      
      MCoercion wraps a coercion, which might be reflexive (MRefl)
      or not (MCo co). To know more about MCoercion see #14975.
      
      We keep Refl ty as a special case for nominal reflexive coercions,
      naemly, Refl ty :: ty ~n ty.
      
      This commit is meant to be a general performance improvement,
      but there are a few regressions. See #15192, comment:13 for
      more information.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, goldfire, simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15192
      
      Differential Revision: https://phabricator.haskell.org/D4747
      55a3f855
  8. 07 Jun, 2018 1 commit
    • Ben Gamari's avatar
      Don't use unsafeGlobalDynFlags in optCoercion · 64c71ce9
      Ben Gamari authored
      This plumbs DynFlags through CoreOpt so optCoercion can finally
      eliminate its usage of `unsafeGlobalDynFlags`.
      
      Note that this doesn't completely eliminate `unsafeGlobalDynFlags`
      usage from this bit of the compiler. A few uses are introduced in
      call-sites where we don't (yet) have ready access to `DynFlags`.
      
      Test Plan: Validate
      
      Reviewers: goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4774
      64c71ce9
  9. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  10. 30 May, 2018 1 commit
    • Ningning Xie's avatar
      Define MCoercion type · 9aac442f
      Ningning Xie authored
      An attempt on #14975:
      During compilation, reflexive casts is discarded for computation.
      Currently in some places we use Maybe coercion as inputs. So if a cast
      is reflexive it is denoted as Nothing, otherwise Just coercion.
      
      This patch defines the type
      
      data MCoercion = MRefl | MCo Coercion
      
      which is isomorphic to Maybe Coercion but useful in a number of places,
      and super-helpful documentation.
      
      Test Plan: validate
      
      Reviewers: bgamari, goldfire, simonpj
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, rwbarton, thomie, carter
      
      GHC Trac Issues: #14975
      
      Differential Revision: https://phabricator.haskell.org/D4699
      9aac442f
  11. 14 May, 2018 1 commit
    • Tobias Dammers's avatar
      Fix performance regressions from #14737 · d92c7556
      Tobias Dammers authored
      See #15019. When removing an unnecessary type equality check in #14737,
      several regression tests failed. The cause was that some coercions that
      are actually Refl coercions weren't passed in as such, which made the
      equality check needlessly complex (Refl coercions can be discarded in
      this particular check immediately, without inspecting the types at all).
      
      We fix that, and get additional performance improvements for free.
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4635
      d92c7556
  12. 01 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Preserve join-point arity in CoreOpt · d4cc74f1
      Simon Peyton Jones authored
      Trac #15108 showed that the simple optimiser in CoreOpt
      was accidentally eta-reducing a join point, so it didn't meet
      its arity invariant.
      
      This patch fixes it.  See Note [Preserve join-binding arity].
      d4cc74f1
  13. 20 Apr, 2018 2 commits
    • Tobias Dammers's avatar
      Remove unnecessary check in simplCast · 2a5bdd9a
      Tobias Dammers authored
      The coercion optimizer will take care of it anyway, and the check is
      prohibitively expensive.
      
      See Trac #14737.
      
      Reviewers: bgamari
      
      Subscribers: simonpj, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4568
      2a5bdd9a
    • Tobias Dammers's avatar
      Caching coercion roles in NthCo and coercionKindsRole refactoring · 2fbe0b51
      Tobias Dammers authored
      While addressing nonlinear behavior related to coercion roles,
      particularly `NthCo`, we noticed that coercion roles are recalculated
      often even though they should be readily at hand already in most cases.
      This patch adds a `Role` to the `NthCo` constructor so that we can cache
      them rather than having to recalculate them on the fly.
      https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the
      approach.
      
      Performance improvement over GHC HEAD, when compiling Grammar.hs (see below):
      
      GHC 8.2.1:
      ```
      ghc Grammar.hs  176.27s user 0.23s system 99% cpu 2:56.81 total
      ```
      
      before patch (but with other optimizations applied):
      ```
      ghc Grammar.hs -fforce-recomp  175.77s user 0.19s system 100% cpu 2:55.78 total
      ```
      
      after:
      ```
      ../../ghc/inplace/bin/ghc-stage2 Grammar.hs  10.32s user 0.17s system 98% cpu 10.678 total
      ```
      
      Introduces the following regressions:
      
      - perf/compiler/parsing001 (possibly false positive)
      - perf/compiler/T9872
      - perf/compil...
      2fbe0b51
  14. 10 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Discard reflexive casts during Simplify · 7bb7f991
      Richard Eisenberg authored
      Trac #14735 (derived from Trac #11735) found that 75% of compile
      time was being spent in simplCast. This patch is the first in a series
      to deal with that problem.
      
      This particular patch actually has very little effect on performance; it
      just refactors simplCast so that it builds Refl coercions less often.
      Refl coercions require us to compute the type to put inside them, and
      even if that's done lazily it is still work and code. Instead we use
      Maybe Coercion with Nothing for Refl. This change also percolates to
      pushCoTyArg and pushValArg.
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14737
      
      Differential Revision: https://phabricator.haskell.org/D4395
      7bb7f991
  15. 25 Jan, 2018 1 commit
  16. 09 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix join-point decision · 66ff794f
      Simon Peyton Jones authored
      This patch moves the "ok_unfolding" test
         from  CoreOpt.joinPointBinding_maybe
         to    OccurAnal.decideJoinPointHood
      
      Previously the occurrence analyser was deciding to make
      something a join point, but the simplifier was reversing
      that decision, which made the decision about /other/ bindings
      invalid.
      
      Fixes Trac #14650.
      66ff794f
  17. 08 Dec, 2017 1 commit
  18. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  19. 28 Apr, 2017 1 commit
  20. 24 Mar, 2017 1 commit
  21. 17 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      No join-point from an INLINE function with wrong arity · a7dbafe9
      Simon Peyton Jones authored
      The main payload of this patch is NOT to make a join-point
      from a function with an INLINE pragma and the wrong arity;
      see Note [Join points and INLINE pragmas] in CoreOpt.
      This is what caused Trac #13413.
      
      But we must do the exact same thing in simpleOptExpr,
      which drove me to the following refactoring:
      
      * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new
        module CoreOpt along with a few others (exprIsConApp_maybe,
        pushCoArg, etc)
      
        This eliminates a module loop altogether (delete
        CoreArity.hs-boot), and stops CoreSubst getting too huge.
      
      * Rename Simplify.matchOrConvertToJoinPoint
           to joinPointBinding_maybe
        Move it to the new CoreOpt
        Use it in simpleOptExpr as well as in Simplify
      
      * Define CoreArity.joinRhsArity and use it
      a7dbafe9
    • Gabor Greif's avatar
      Typos in manual and comments [ci skip] · 7a38783b
      Gabor Greif authored
      7a38783b
  22. 01 Mar, 2017 1 commit
    • David Feuer's avatar
      Upgrade UniqSet to a newtype · cbe569a5
      David Feuer authored
      The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
      has a key invariant `UniqFM` does not. For example, `fmap` over
      `UniqSet` will generally produce nonsense.
      
      * Upgrade `UniqSet` from a type synonym to a newtype.
      
      * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`.
      
      * Use cached unique in `tyConsOfType` by replacing
        `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.
      
      Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari
      
      Reviewed By: niteria
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3146
      cbe569a5
  23. 28 Feb, 2017 1 commit
  24. 24 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Make exprIsConApp_maybe work better for literals strings · a6e13d50
      Simon Peyton Jones authored
      There are two things here
      
      * Use exprIsLiteral_maybe to "look through" a variable bound
        to a literal string.
      
      * Add CONLIKE to the NOINLINE pragma for unpackCString# and
        unpackCStringUtf8#
      
      See Trac #13317, Trac #10844, and
      Note [exprIsConApp_maybe on literal strings] in CoreSubst
      
      I did a nofib run and got essentially zero change except for one
      2.2% improvement in allocation for 'pretty'.
      a6e13d50
  25. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Generalize kind of the (->) tycon · b207b536
      Ben Gamari authored
      This is generalizes the kind of `(->)`, as discussed in #11714.
      
      This involves a few things,
      
       * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
      binders,
        ```lang=haskell
      (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                     (a :: TYPE r1) (b :: TYPE r2).
              a -> b -> *
        ```
      
       * Unsaturated applications of `(->)` are expressed as explicit
      `TyConApp`s
      
       * Saturated applications of `(->)` are expressed as `FunTy` as they are
      currently
      
       * Saturated applications of `(->)` are expressed by a new `FunCo`
      constructor in coercions
      
       * `splitTyConApp` needs to ensure that `FunTy`s are split to a
      `TyConApp`
         of `(->)` with the appropriate `RuntimeRep` arguments
      
       * Teach CoreLint to check that all saturated applications of `(->)` are
      represented with `FunTy`
      
      At the moment I assume that `Constraint ~ *`, which is an annoying
      source of complexity. This will
      be simplified once D3023 is resolved.
      
      Also, this introduces two known regressions,
      
      `tcfail181`, `T10403`
      =====================
      Only shows the instance,
      
          instance Monad ((->) r) -- Defined in ‘GHC.Base’
      
      in its error message when -fprint-potential-instances is used. This is
      because its instance head now mentions 'LiftedRep which is not in scope.
      I'm not entirely sure of the right way to fix this so I'm just accepting
      the new output for now.
      
      T5963 (Typeable)
      ================
      
      T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
      fingerprint without the RuntimeRep variables that (->) expects. This
      will be fixed with the merge of D2010.
      
      Haddock performance
      ===================
      
      The `haddock.base` and `haddock.Cabal` tests regress in allocations by
      about 20%. This certainly hurts, but it's also not entirely unexpected:
      the size of every function type grows with this patch and Haddock has a
      lot of functions in its heap.
      b207b536
  26. 08 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve the simple optimiser · 8e9593fb
      Simon Peyton Jones authored
      The previous version of the simple optimiser would leave
      beta-redexes, which was bad for join points.  E.g.
      
        join j x = ....   -- a join point
        in (\x. j x) y
      
      This would be ok if we beta-reduced the (\x) but not if
      we don't.
      
      This patch improves the simple optimiser, to follow the plan
      described in "Secrets of the GHC inliner", and implemented in
      the Mighty Simplifier.  It turns out not to be too hard to
      use the same plan here, and we get slightly better code as
      a result.
      8e9593fb
  27. 01 Feb, 2017 1 commit
  28. 23 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Record evaluated-ness on workers and wrappers · 596dece7
      Simon Peyton Jones authored
      Summary:
      This patch is a refinement of the original commit (which
      was reverted):
      
        commit 6b976eb8
        Date:   Fri Jan 13 08:56:53 2017 +0000
            Record evaluated-ness on workers and wrappers
      
      In Trac #13027, comment:20, I noticed that wrappers created after
      demand analysis weren't recording the evaluated-ness of strict
      constructor arguments.  In the ticket that led to a (debatable)
      Lint error but in general the more we know about evaluated-ness
      the better we can optimise.
      
      This commit adds that info
        * both in the worker (on args)
        * and in the wrapper (on CPR result patterns).
      See Note [Record evaluated-ness in worker/wrapper] in WwLib
      
      On the way I defined Id.setCaseBndrEvald, and used it to shorten
      the code in a few other places
      
      Then I added test T13077a to test the CPR aspect of this patch,
      but I found that Lint failed!
      
      Reason: simpleOptExpr was discarding evaluated-ness info on
      lambda binders because zapFragileIdInfo was discarding an
      Unfolding of (OtherCon _).  But actually that's a robust
      unfolding; there is no need to discard it. To fix this:
      
      * zapFragileIdInfo only zaps fragile unfoldings
      
      * Replace isClosedUnfolding with isFragileUnfolding (the latter
        is just the negation of the former, but the nomenclature is
        more consistent).  Better documentation too
             Note [Fragile unfoldings]
      
      * And Simplify.simplLamBndr can now look at isFragileUnfolding
        to decide whether to use the longer route of simplUnfolding.
      
      For some reason perf/compiler/T9233 improves in compile-time
      allocation by 10%.  Hooray
      
      Nofib: essentially no change:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
            cacheprof          +0.0%     -0.3%     +0.9%     +0.4%     +0.0%
      --------------------------------------------------------------------------------
                  Min          +0.0%     -0.3%     -2.4%     -2.4%     +0.0%
                  Max          +0.0%     +0.0%     +9.8%    +11.4%     +2.4%
       Geometric Mean          +0.0%     -0.0%     +1.1%     +1.0%     +0.0%
      596dece7
  29. 20 Jan, 2017 1 commit
    • takano-akio's avatar
      Allow top-level string literals in Core (#8472) · d49b2bb2
      takano-akio authored
      This commits relaxes the invariants of the Core syntax so that a
      top-level variable can be bound to a primitive string literal of type
      Addr#.
      
      This commit:
      
      * Relaxes the invatiants of the Core, and allows top-level bindings whose
        type is Addr# as long as their RHS is either a primitive string literal or
        another variable.
      
      * Allows the simplifier and the full-laziness transformer to float out
        primitive string literals to the top leve.
      
      * Introduces the new StgGenTopBinding type to accomodate top-level Addr#
        bindings.
      
      * Introduces a new type of labels in the object code, with the suffix "_bytes",
        for exported top-level Addr# bindings.
      
      * Makes some built-in rules more robust. This was necessary to keep them
        functional after the above changes.
      
      This is a continuation of D2554.
      
      Rebasing notes:
      This had two slightly suspicious performance regressions:
      
      * T12425: bytes allocated regressed by roughly 5%
      * T4029: bytes allocated regressed by a bit over 1%
      * T13035: bytes allocated regressed by a bit over 5%
      
      These deserve additional investigation.
      
      Rebased by: bgamari.
      
      Test Plan: ./validate --slow
      
      Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari
      
      Reviewed By: trofi, simonpj, bgamari
      
      Subscribers: trofi, simonpj, gridaphobe, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2605
      
      GHC Trac Issues: #8472
      d49b2bb2
  30. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  31. 06 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix the implementation of the "push rules" · b4f2afe7
      Simon Peyton Jones authored
      Richard pointed out (comment:12 of Trac #13025) that my
      implementation of the coercion "push rules", newly added
      in exprIsConAppMaybe by commit b4c3a668, wasn't quite right.
      
      But in fact that means that the implementation of those same
      rules in Simplify.simplCast was wrong too.
      
      Hence this commit:
      
      * Refactor the push rules so they are implemented in just
        one place (CoreSubst.pushCoArgs, pushCoTyArg, pushCoValArg)
        The code in Simplify gets simpler, which is nice.
      
      * Fix the bug that Richard pointed out (to do with hetero-kinded
        coercions)
      
      Then compiler performance worsened, which led mt do discover
      two performance bugs:
      
      * The smart constructor Coercion.mkNthCo didn't have a case
        for ForAllCos, which meant we stupidly build a complicated
        coercion where a simple one would do
      
      * In OptCoercion there was one place where we used CoherenceCo
        (the data constructor) rather than mkCoherenceCo (the smart
        constructor), which meant that the the stupid complicated
        coercion wasn't optimised away
      
      For reasons I don't fully understand, T5321Fun did 2% less compiler
      allocation after all this, which is good.
      b4f2afe7
  32. 23 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Push coercions in exprIsConApp_maybe · b4c3a668
      Simon Peyton Jones authored
      Trac #13025 showed up the fact that exprIsConApp_maybe isn't
      clever enough: it didn't push coercions through applicatins, and that
      meant we weren't getting as much superclass selection as we should.
      
      It's easy to fix, happily.
      
      See Note [Push coercions in exprIsConApp_maybe]
      b4c3a668
  33. 21 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Move InId/OutId to CoreSyn · 05d233e8
      Simon Peyton Jones authored
      It turned out that many different modules defined the same type
      synonyms (InId, OutId, InType, OutType, etc) for the same purpose.
      
      This patch is refactoring only: it moves all those definitions to
      CoreSyn.
      05d233e8
  34. 05 Aug, 2016 1 commit
  35. 12 May, 2016 1 commit
  36. 20 Apr, 2016 1 commit
    • niteria's avatar
      Rename FV related functions · 2e33320a
      niteria authored
      This is from Simon's suggestion:
      
      * `tyCoVarsOfTypesAcc` is a terrible name for a function with a
        perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`?
        Similarly others
      
      * `runFVList` is also terrible, but also has a decent type.
        Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`).
      
      * `someVars` could be `mkFVs :: [Var] -> FV`.
      2e33320a
  37. 30 Mar, 2016 1 commit