This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 14 Mar, 2017 1 commit
  2. 23 Feb, 2017 1 commit
  3. 15 Feb, 2017 1 commit
  4. 09 Feb, 2017 1 commit
  5. 07 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Another improvement to SetLevels · b8f58d79
      Simon Peyton Jones authored
      In my recent commit
         commit 432f952e
         Float unboxed expressions by boxing
      I changed how float_me in lvlMFE worked.  That was right, but
      it exposed another bug: an error expression wasn't getting floated
      as it should from a case alternative.  And that led to a collection
      of minor improvements
      
      * I found a much better way to cast it, by using lvlFloatRhs for
        top-level bindinds as well as nested ones, which is
          (a) more consistent and
          (b) works correctly.
      
        See Note [Floating from a RHS]
      
      * I also found some delicacy in the "floating to the top" stuff, so I
        greatly elaborated the Note [Floating to the top].
      
      * I simplified the "bottoming-float" stuff; the change is in the treatment
        of bottoming lambdas (\x y. error blah), where we now float the
        (error blah) part instead of the whole lambda (which risks just making
        duplicate lambdas.  See Note [Bottoming floats], esp (2).
      
      Perf effects are minor.
      
      * perf/compiler/T13056 improved sligtly (about 2%) in compiler
        allocations. Also T9233 improved by 1%.  I'm not sure why.
      
      * Some small nofib changes:
          - Generally some very small reductions in run-time
            allocation, except k-nucleotide, which halves for some
            reason.  (I did try to look but it's a big complicated
            function and it was far from obvious.  Had it been a loss
            I would have looked harder!
      
      NB: there's a nearby patch "Do not inline bottoming things" that could
      also be responsible for either or both.  I didn't think it was worth
      more testing to distinguish.
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                 grep          +0.1%     -0.2%      0.00      0.00     +0.0%
               mandel          -0.1%     -1.4%      0.13      0.13     +0.0%
         k-nucleotide          +0.1%    -51.6%     -1.0%     -1.0%     +0.0%
      --------------------------------------------------------------------------------
                  Min          -0.3%    -51.6%     -9.4%     -9.1%     -4.0%
                  Max          +0.2%     +0.0%    +31.8%    +32.7%     +0.0%
       Geometric Mean          -0.0%     -0.8%     +1.4%     +1.4%     -0.1%
      b8f58d79
  6. 01 Feb, 2017 2 commits
  7. 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
  8. 20 Jan, 2017 2 commits
    • takano-akio's avatar
      Allow top-level string literals in Core (#8472) · d49b2bb2
      takano-akio authored and Ben Gamari's avatar Ben Gamari committed
      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
    • Simon Peyton Jones's avatar
      Fix a nasty bug in exprIsExpandable · 9be18ea4
      Simon Peyton Jones authored
      This bug has been lurking for ages: Trac #13155
      
      The important semantic change is to ensure that exprIsExpandable
      returns False for primop calls.  Previously exprIsExpandable used
      exprIsCheap' which always used primOpIsCheap.
      
      I took the opportunity to combine the code for exprIsCheap' (two
      variants: exprIsCheap and exprIsExpandable) with that for
      exprIsWorkFree.  Result is simpler, tighter, easier to understand.
      And correct (at least wrt this bug)!
      9be18ea4
  9. 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
  10. 18 Jan, 2017 1 commit
  11. 16 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refine exprOkForSpeculation · 5a9a1738
      Simon Peyton Jones authored
      This patch implements two related changes, both inspired by
      the discussion on Trac #13027, comment:23:
      
      * exprOkForSpeculation (op# a1 .. an), where op# is a primop,
        now skips over arguments ai of lifted type.  See the comments
        at Note [Primops with lifted arguments] in CoreUtils.
      
        There is no need to treat dataToTag# specially any more.
      
      * dataToTag# is now treated as a can-fail primop.  See
        Note [dataToTag#] in primops.txt.pp
      
      I don't expect this to have a visible effect on anything, but
      it's much more solid than before.
      5a9a1738
  12. 15 Jan, 2017 1 commit
  13. 13 Jan, 2017 2 commits
    • Facundo Domínguez's avatar
      Desugar static forms to makeStatic calls. · 13a85211
      Facundo Domínguez authored
      Summary:
      Using makeStatic instead of applications of the StaticPtr data
      constructor makes possible linting core when unboxing strict
      fields.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari, hvr
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, mboes, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2930
      
      GHC Trac Issues: #12622
      13a85211
    • Simon Peyton Jones's avatar
      Record evaluated-ness on workers and wrappers · 6b976eb8
      Simon Peyton Jones authored
      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
      6b976eb8
  14. 12 Jan, 2017 1 commit
  15. 06 Jan, 2017 2 commits
  16. 16 Dec, 2016 1 commit
  17. 15 Nov, 2016 1 commit
  18. 12 Oct, 2016 1 commit
  19. 21 Aug, 2016 1 commit
  20. 28 Jun, 2016 1 commit
    • Facundo Domínguez's avatar
      Stop the simplifier from removing StaticPtr binds. · dd92c67b
      Facundo Domínguez authored
      Summary:
      We have the FloatOut pass create exported ids for floated StaticPtr
      bindings. The simplifier doesn't try to remove those.
      
      This patch also improves on 7fc20b by making a common definition
      collectStaticPtrSatArgs to test for StaticPtr binds.
      
      Fixes #12207.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, bgamari, simonmar, goldfire
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2366
      
      GHC Trac Issues: #12207
      dd92c67b
  21. 22 Jun, 2016 1 commit
  22. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  23. 09 Jun, 2016 1 commit
    • Edward Z. Yang's avatar
      Fix #12076 by inlining trivial expressions in CorePrep. · 11ff1df8
      Edward Z. Yang authored
      
      
      Summary:
      This mostly follows the plan detailed by the discussion
      Simon and I had, with one difference: instead of grabbing
      the free variables of the trivial expressions to get the
      embedded Ids, we just use getIdFromTrivialExpr_maybe to extract
      out the Id.  If there is no Id, the expression cannot
      refer to a function (as there are no literal functions)
      and thus we do not need to saturate.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2309
      
      GHC Trac Issues: #12076
      11ff1df8
  24. 20 Apr, 2016 1 commit
    • niteria's avatar
      Build a correct substitution in dataConInstPat · 62943d2a
      niteria authored
      This adds the tyvars of the domain of the substitution into the in-scope
      set as well.
      What I'm not sure here is if the kinds can have any free vars that
      should be in the in-scope set as well.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2094
      
      GHC Trac Issues: #11371
      62943d2a
  25. 08 Apr, 2016 1 commit
  26. 29 Mar, 2016 1 commit
  27. 18 Feb, 2016 2 commits
    • Simon Peyton Jones's avatar
      Improve piResultTys and friends · 4d031cf9
      Simon Peyton Jones authored
      Several things here:
      
      * Re-implement piResultTys so that its substitution has
        the correct in-scope set
      
        That means paying close attention to performance, since as we
        discovered in Trac #11371, it's a heavily used function and
        is often used on ordinary function types, with no foralls to
        worry about substituting.
      
      * Kill off applyTys, which was just the same as piResultTys.
      
      * Re-engineer MkCore.mkCoreApps so that it calls piResultTys,
        rather than repeatedly calling piResultTy.
      4d031cf9
    • Simon Peyton Jones's avatar
      (Another) minor refactoring of substitutions · b5292557
      Simon Peyton Jones authored
      No change in functionality here, but greater clarity:
      
      * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
        We are already maintaining an in-scope set in the fe_subst field,
        so it's silly do to it twice.
      
        (This isn't strictly connected to the rest of this patch, but
        the nomenclature changes below affect the same code, so I put
        them together.)
      
      * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
        out what to do, but in fact we almost always know which of the
        two we are doing.  So:
          - define extendTvSubst, extendCvSubst
          - and use them
      
      * Similar renamings in TyCoRep:
         - extendTCvSubstList        -->   extendTvSubstList
         - extendTCvSubstBinder      -->   extendTvSubstBinder
         - extendTCvSubstAndInScope  --> extendTvSubstAndInScope
      
      * Add Type.extendTvSubstWithClone, extendCvSubstWithClone
      
      * Similar nomenclature changes in Subst, SimplEnv, Specialise
      
      * Kill off TyCoRep.substTelescope (never used)
      b5292557
  28. 30 Jan, 2016 1 commit
    • niteria's avatar
      Add asserts to other substitution functions · bb956eb8
      niteria authored
      This adds asserts to `substTys`, `substCo` and `substCos` in
      the same spirit as already existing asserts on `substTy`, protecting
      every possible entry point to `subst_ty` and `subst_co`.
      
      I've replaced the violators with unchecked versions.
      
      Test Plan: ./validate --slow
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1862
      
      GHC Trac Issues: #11371
      bb956eb8
  29. 27 Jan, 2016 2 commits
    • niteria's avatar
      Rename "open" subst functions · 5dcae88b
      niteria authored
      This is the renaming that @simonpj requested:
      ```
      · zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)
      
      · zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with
      covars)
      
      · zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals
      with TyBinders, not covars)
      ```
      plus the `mk` variant.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1853
      
      GHC Trac Issues: #11371
      5dcae88b
    • Ömer Sinan Ağacan's avatar
      s/unLifted/unlifted for consistency · 4faa1a63
      Ömer Sinan Ağacan authored and Ben Gamari's avatar Ben Gamari committed
      This was causing trouble as we had to remember when to use "unLifted"
      and when to use "unlifted".
      
      "unlifted" is used instead of "unLifted" as it's a single word.
      
      Reviewers: austin, hvr, goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1852
      4faa1a63
  30. 25 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix exprIsHNF (Trac #11248) · 3c060f36
      Simon Peyton Jones authored
      Blimey!  CoreUtils.exprIsHNFlike had not one but two bugs.
      
       * is_hnf_like treated coercion args like type args
         (result: exprIsHNF might wrongly say True)
      
       * app_is_value treated type args like value args
         (result: exprIsHNF might wrongly say False)
      
      Bizarre.  This goes back to at least 2012. It's amazing that it
      hasn't caused more trouble.
      
      It was discovered by a Lint error when compiling Trac #11248 with -O.
      3c060f36
  31. 20 Jan, 2016 2 commits
    • Simon Peyton Jones's avatar
      Oops. Add missing close-comment · 0373a845
      Simon Peyton Jones authored
      This fixes 514bac26 for Trac #11172.  Sorry!
      0373a845
    • Simon Peyton Jones's avatar
      Fix combineIdenticalAlts · 514bac26
      Simon Peyton Jones authored
      This long-standing bug in CoreUtils.combineIdenticalAlts
      was shown up by Trac #11172. The effect was that it returned
      a correct set of alternatives, but a bogus set of "impossible
      default constructors".  That meant that we subsequently
      removed all the alternatives from a case, and hence ended
      up with a bogusly empty case that should not have been empty.
      
      See Note [Care with impossible-constructors when
      combining alternatives] in CoreUtils.
      514bac26
  32. 19 Jan, 2016 1 commit
    • niteria's avatar
      Check InScopeSet in substTy and provide substTyUnchecked · 9d33adb6
      niteria authored
      This adds sanity checks to `substTy` that implement:
      
      > when calling substTy subst ty it should be the case that the in-scope
      > set in the substitution is a superset of
      > * The free vars of the range of the substitution
      > * The free vars of ty minus the domain of the substitution
      
      and replaces violators with unchecked version. The violators were found
      by running the GHC test suite.
      
      This ensures that I can work on this incrementally and that what I fix won't
      be undone by some other change.
      
      It also includes a couple of fixes that I've already done.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1792
      
      GHC Trac Issues: #11371
      9d33adb6
  33. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852