Skip to content
Snippets Groups Projects
  1. Oct 10, 2023
  2. Oct 05, 2023
  3. Oct 04, 2023
  4. Sep 28, 2023
  5. Sep 16, 2023
    • Simon Peyton Jones's avatar
      Use correct FunTyFlag in adjustJoinPointType · 8e05c54a
      Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
      As the Lint error in #23952 showed, the function adjustJoinPointType
      was failing to adjust the FunTyFlag when adjusting the type.
      
      I don't think this caused the seg-fault reported in the ticket,
      but it is definitely.  This patch fixes it.
      
      It is tricky to come up a small test case; Krzysztof came up with
      this one, but it only triggers a failure in GHC 9.6.
      8e05c54a
  6. Sep 13, 2023
    • Simon Peyton Jones's avatar
      Fix eta reduction · 6840012e
      Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
      Issue #23922 showed that GHC was bogusly eta-reducing a join point.
      We should never eta-reduce (\x -> j x) to j, if j is a join point.
      
      It is extremly difficult to trigger this bug.  It took me 45 mins of
      trying to make a small tests case, here immortalised as T23922a.
      6840012e
    • Ben Gamari's avatar
      spec-constr: Lift argument limit for SPEC-marked functions · 56b403c9
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      When the user adds a SPEC argument to a function, they are informing us
      that they expect the function to be specialised. However, previously
      this instruction could be preempted by the specialised-argument limit
      (sc_max_args). Fix this.
      
      This fixes #14003.
      56b403c9
  7. Sep 07, 2023
    • Krzysztof Gogolewski's avatar
      Fix wrong role in mkSelCo_maybe · e0aa8c6e
      Krzysztof Gogolewski authored and Marge Bot's avatar Marge Bot committed
      In the Lint failure in #23938, we start with a coercion Refl :: T a ~R T a,
      and call mkSelCo (SelTyCon 1 nominal) Refl.
      The function incorrectly returned Refl :: a ~R a. The returned role
      should be nominal, according to the SelCo rule:
      
            co : (T s1..sn) ~r0 (T t1..tn)
            r = tyConRole tc r0 i
            ----------------------------------
            SelCo (SelTyCon i r) : si ~r ti
      
      In this test case, r is nominal while r0 is representational.
      e0aa8c6e
  8. Aug 28, 2023
    • Zubin's avatar
      testsuite: Add regression test for #23864 · b6903f4d
      Zubin authored and Marge Bot's avatar Marge Bot committed
      Simon says this was fixed by
      
      commit 59202c80
      Author: Sebastian Graf <sebastian.graf@kit.edu>
      Date:   Fri Mar 31 17:35:22 2023 +0200
      
          CorePrep: Eliminate EmptyCase and unsafeEqualityProof in CoreToStg instead
      
          We eliminate EmptyCase by way of `coreToStg (Case e _ _ []) = coreToStg e` now.
          The main reason is that it plays far better in conjunction with eta expansion
          (as we aim to do for arguments in CorePrep, #23083), because we can discard
          any arguments, `(case e of {}) eta == case e of {}`, whereas in `(e |> co) eta`
          it's impossible to discard the argument.
      b6903f4d
  9. Aug 09, 2023
    • Sebastian Graf's avatar
      CorePrep: Eta expand arguments (#23083) · 00d31188
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      Previously, we'd only eta expand let bindings and lambdas,
      now we'll also eta expand arguments such as in T23083:
      ```hs
      g f h = f (h `seq` (h $))
      ```
      Unless `-fpedantic-bottoms` is set, we'll now transform to
      ```hs
      g f h = f (\eta -> h eta)
      ```
      in CorePrep.
      
      See the new `Note [Eta expansion of arguments in CorePrep]` for the details.
      
      We only do this optimisation with -O2 because we saw 2-3% ghc/alloc regressions
      in T4801 and T5321FD.
      
      Fixes #23083.
      00d31188
    • Sebastian Graf's avatar
      Core.Ppr: Omit case binder for empty case alternatives · 8c73505e
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      A minor improvement to pretty-printing
      8c73505e
  10. Aug 03, 2023
  11. Jul 30, 2023
    • Simon Peyton Jones's avatar
      Make the occurrence analyser smarter about join points · d0369802
      Simon Peyton Jones authored and Simon Peyton Jones's avatar Simon Peyton Jones committed
      This MR addresses #22404.  There is a big Note
      
         Note [Occurrence analysis for join points]
      
      that explains it all.  Significant changes
      
      * New field occ_join_points in OccEnv
      
      * The NonRec case of occAnalBind splits into two cases:
        one for existing join points (which does the special magic for
        Note [Occurrence analysis for join points], and one for other
        bindings.
      
      * mkOneOcc adds in info from occ_join_points.
      
      * All "bring into scope" activity is centralised in the
        new function `addInScope`.
      
      * I made a local data type LocalOcc for use inside the occurrence analyser
        It is like OccInfo, but lacks IAmDead and IAmALoopBreaker, which in turn
        makes computationns over it simpler and more efficient.
      
      * I found quite a bit of allocation in GHC.Core.Rules.getRules
        so I optimised it a bit.
      
      More minor changes
      
      * I found I was using (Maybe Arity) a lot, so I defined a new data
        type JoinPointHood and used it everwhere.  This touches a lot of
        non-occ-anal files, but it makes everything more perspicuous.
      
      * Renamed data constructor WithUsageDetails to WUD, and
        WithTailUsageDetails to WTUD
      
      This also fixes #21128, on the way.
      
      --------- Compiler perf -----------
      I spent quite a time on performance tuning, so even though it
      does more than before, the occurrence analyser runs slightly faster
      on average.  Here are the compile-time allocation changes over 0.5%
      
            CoOpt_Read(normal) ghc/alloc    766,025,520    754,561,992  -1.5%
      CoOpt_Singletons(normal) ghc/alloc    759,436,840    762,925,512  +0.5%
           LargeRecord(normal) ghc/alloc  1,814,482,440  1,799,530,456  -0.8%
             PmSeriesT(normal) ghc/alloc     68,159,272     67,519,720  -0.9%
                T10858(normal) ghc/alloc    120,805,224    118,746,968  -1.7%
                T11374(normal) ghc/alloc    164,901,104    164,070,624  -0.5%
                T11545(normal) ghc/alloc     79,851,808     78,964,704  -1.1%
                T12150(optasm) ghc/alloc     73,903,664     71,237,544  -3.6% GOOD
                T12227(normal) ghc/alloc    333,663,200    331,625,864  -0.6%
                T12234(optasm) ghc/alloc     52,583,224     52,340,344  -0.5%
                T12425(optasm) ghc/alloc     81,943,216     81,566,720  -0.5%
                T13056(optasm) ghc/alloc    294,517,928    289,642,512  -1.7%
            T13253-spj(normal) ghc/alloc    118,271,264     59,859,040 -49.4% GOOD
                T15164(normal) ghc/alloc  1,102,630,352  1,091,841,296  -1.0%
                T15304(normal) ghc/alloc  1,196,084,000  1,166,733,000  -2.5%
                T15630(normal) ghc/alloc    148,729,632    147,261,064  -1.0%
                T15703(normal) ghc/alloc    379,366,664    377,600,008  -0.5%
                T16875(normal) ghc/alloc     32,907,120     32,670,976  -0.7%
                T17516(normal) ghc/alloc  1,658,001,888  1,627,863,848  -1.8%
                T17836(normal) ghc/alloc    395,329,400    393,080,248  -0.6%
                T18140(normal) ghc/alloc     71,968,824     73,243,040  +1.8%
                T18223(normal) ghc/alloc    456,852,568    453,059,088  -0.8%
                T18282(normal) ghc/alloc    129,105,576    131,397,064  +1.8%
                T18304(normal) ghc/alloc     71,311,712     70,722,720  -0.8%
               T18698a(normal) ghc/alloc    208,795,112    210,102,904  +0.6%
               T18698b(normal) ghc/alloc    230,320,736    232,697,976  +1.0%  BAD
                T19695(normal) ghc/alloc  1,483,648,128  1,504,702,976  +1.4%
                T20049(normal) ghc/alloc     85,612,024     85,114,376  -0.6%
               T21839c(normal) ghc/alloc    415,080,992    410,906,216  -1.0% GOOD
                 T4801(normal) ghc/alloc    247,590,920    250,726,272  +1.3%
                 T6048(optasm) ghc/alloc     95,699,416     95,080,680  -0.6%
                  T783(normal) ghc/alloc    335,323,384    332,988,120  -0.7%
                 T9233(normal) ghc/alloc    709,641,224    685,947,008  -3.3% GOOD
                 T9630(normal) ghc/alloc    965,635,712    948,356,120  -1.8%
                 T9675(optasm) ghc/alloc    444,604,152    428,987,216  -3.5% GOOD
                 T9961(normal) ghc/alloc    303,064,592    308,798,800  +1.9%  BAD
                 WWRec(normal) ghc/alloc    503,728,832    498,102,272  -1.1%
      
                     geo. mean                                          -1.0%
                     minimum                                           -49.4%
                     maximum                                            +1.9%
      
      In fact these figures seem to vary between platforms; generally worse
      on i386 for some reason.  The Windows numbers vary by 1% espec in
      benchmarks where the total allocation is low. But the geom mean stays
      solidly negative, which is good.  The "increase/decrease" list below
      covers all platforms.
      
      The big win on T13253-spj comes because it has a big nest of join
      points, each occurring twice in the next one.  The new occ-anal takes
      only one iteration of the simplifier to do the inlining; the old one
      took four.  Moreover, we get much smaller code with the new one:
      
        New: Result size of Tidy Core
          = {terms: 429, types: 84, coercions: 0, joins: 14/14}
      
        Old: Result size of Tidy Core
          = {terms: 2,437, types: 304, coercions: 0, joins: 10/10}
      
      --------- Runtime perf -----------
      No significant changes in nofib results, except a 1% reduction in
      compiler allocation.
      
      Metric Decrease:
          CoOpt_Read
          T13253-spj
          T9233
          T9630
          T9675
          T12150
          T21839c
          LargeRecord
          MultiComponentModulesRecomp
          T10421
          T13701
          T10421
          T13701
          T12425
      
      Metric Increase:
          T18140
          T9961
          T18282
          T18698a
          T18698b
          T19695
      d0369802
  12. Jul 22, 2023
  13. Jul 15, 2023
    • Matthew Craven's avatar
      Equality of forall-types is visibility aware · cf86f3ec
      Matthew Craven authored and Vladislav Zavialov's avatar Vladislav Zavialov committed
      This patch finally (I hope) nails the question of whether
         (forall a. ty) and (forall a -> ty)
      are `eqType`: they aren't!
      
      There is a long discussion in #22762, plus useful Notes:
      
      * Note [ForAllTy and type equality] in GHC.Core.TyCo.Compare
      * Note [Comparing visiblities] in GHC.Core.TyCo.Compare
      * Note [ForAllCo] in GHC.Core.TyCo.Rep
      
      It also establishes a helpful new invariant for ForAllCo,
      and ForAllTy, when the bound variable is a CoVar:in that
      case the visibility must be coreTyLamForAllTyFlag.
      
      All this is well documented in revised Notes.
      cf86f3ec
  14. Jul 13, 2023
  15. Jul 06, 2023
  16. Jul 05, 2023
    • Torsten Schmits's avatar
      Substitute free variables captured by breakpoints in SpecConstr · 40f4ef7c
      Torsten Schmits authored and Marge Bot's avatar Marge Bot committed
      Fixes #23267
      40f4ef7c
    • meooow's avatar
      Improve the situation with the stimes cycle · 9ce44336
      meooow authored and Marge Bot's avatar Marge Bot committed
      Currently the Semigroup stimes cycle is resolved in GHC.Base by
      importing stimes implementations from a hs-boot file. Resolve the cycle
      using hs-boot files for required classes (Num, Integral) instead. Now
      stimes can be defined directly in GHC.Base, making inlining and
      specialization possible.
      
      This leads to some new boot files for `GHC.Num` and `GHC.Real`, the
      methods for those are only used to implement `stimes` so it doesn't
      appear that these boot files will introduce any new performance traps.
      
      Metric Decrease:
          T13386
          T8095
      Metric Increase:
          T13253
          T13386
          T18698a
          T18698b
          T19695
          T8095
      9ce44336
    • Vladislav Zavialov's avatar
      testsuite: Do not require CUSKs · 679bbc97
      Vladislav Zavialov authored and Marge Bot's avatar Marge Bot committed
      Numerous tests make use of CUSKs (complete user-supplied kinds),
      a legacy feature scheduled for deprecation. In order to proceed
      with the said deprecation, the tests have been updated to use SAKS
      instead (standalone kind signatures).
      
      This also allows us to remove the Haskell2010 language pragmas that
      were added in 115cd3c8 to work around the lack of CUSKs in GHC2021.
      679bbc97
  17. Jun 29, 2023
  18. Jun 21, 2023
  19. Jun 14, 2023
  20. Jun 13, 2023
  21. May 23, 2023
    • Simon Peyton Jones's avatar
      Avoid an assertion failure in abstractFloats · 6abf3648
      Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
      The function GHC.Core.Opt.Simplify.Utils.abstractFloats
      was carelessly calling lookupIdSubst_maybe on a CoVar;
      but a precondition of the latter is being given an Id.
      
      In fact it's harmless to call it on a CoVar, but still, the
      precondition on lookupIdSubst_maybe makes sense, so I added
      a test for CoVars.
      
      This avoids a crash in a DEBUG compiler, but otherwise has
      no effect. Fixes #23426.
      6abf3648
  22. May 15, 2023
    • Matthew Farkas-Dyck's avatar
      Unbreak some tests with latest GNU grep, which now warns about stray '\'. · e305e60c
      Matthew Farkas-Dyck authored and Marge Bot's avatar Marge Bot committed
      Confusingly, the testsuite mangled the error to say "stray /".
      
      We also migrate some tests from grep to grep -E, as it seems the author actually wanted an "POSIX extended" (a.k.a. sane) regex.
      
      Background: POSIX specifies 2 "regex" syntaxen: "basic" and "extended". Of these, only "extended" syntax is actually a regular expression. Furthermore, "basic" syntax is inconsistent in its use of the '\' character — sometimes it escapes a regex metacharacter, but sometimes it unescapes it, i.e. it makes an otherwise normal character become a metacharacter. This baffles me and it seems also the authors of these tests. Also, the regex(7) man page (at least on Linux) says "basic" syntax is obsolete. Nearly all modern tools and libraries are consistent in this use of the '\' character (of which many use "extended" syntax by default).
      e305e60c
  23. May 13, 2023
  24. May 12, 2023
  25. May 06, 2023
  26. Apr 26, 2023
    • Sebastian Graf's avatar
      DmdAnal: Unleash demand signatures of free RULE and unfolding binders (#23208) · c30ac25f
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      In #23208 we observed that the demand signature of a binder occuring in a RULE
      wasn't unleashed, leading to a transitively used binder being discarded as
      absent. The solution was to use the same code path that we already use for
      handling exported bindings.
      
      See the changes to `Note [Absence analysis for stable unfoldings and RULES]`
      for more details.
      
      I took the chance to factor out the old notion of a `PlusDmdArg` (a pair of a
      `VarEnv Demand` and a `Divergence`) into `DmdEnv`, which fits nicely into our
      existing framework. As a result, I had to touch quite a few places in the code.
      
      This refactoring exposed a few small bugs around correct handling of bottoming
      demand environments. As a result, some strictness signatures now mention uniques
      that weren't there before which caused test output changes to T13143, T19969 and
      T22112. But these tests compared whole -ddump-simpl listings which is a very
      fragile thing to begin with. I changed what exactly they test for based on the
      symptoms in the corresponding issues.
      
      There is a single regression in T18894 because we are more conservative around
      stable unfoldings now. Unfortunately it is not easily fixed; let's wait until
      there is a concrete motivation before invest more time.
      
      Fixes #23208.
      c30ac25f
  27. Apr 25, 2023
    • Andrei Borzenkov's avatar
      Give more guarntees about ImplicitParams (#23289) · 74c55712
      Andrei Borzenkov authored and Marge Bot's avatar Marge Bot committed
      - Added new section in the GHC user's guide that legends behavior of
      nested implicit parameter bindings in these two cases:
      
        let ?f = 1 in let ?f = 2 in ?f
      
      and
      
        data T where MkT :: (?f :: Int) => T
      
        f :: T -> T -> Int
        f MkT MkT = ?f
      
      - Added new test case to examine this behavior.
      74c55712
  28. Apr 20, 2023
  29. Apr 04, 2023
  30. Apr 01, 2023
    • Matthew Pickering's avatar
      Add test for T23184 · 0077cb22
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      There was an outright bug, which Simon fixed in July 2021, as a little side-fix on a complicated patch:
      
      ```
      commit 6656f016
      Author: Simon Peyton Jones <simonpj@microsoft.com>
      Date:   Fri Jul 23 23:57:01 2021 +0100
      
          A bunch of changes related to eta reduction
      
          This is a large collection of changes all relating to eta
          reduction, originally triggered by #18993, but there followed
          a long saga.
      
          Specifics:
      
      ...lots of lines omitted...
      
          Other incidental changes
      
          * Fix a fairly long-standing outright bug in the ApplyToVal case of
            GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
            tail of 'dmds' in the recursive call, which meant the demands were All
            Wrong.  I have no idea why this has not caused problems before now.
      ```
      
      Note this "Fix a fairly longstanding outright bug".   This is the specific fix
      ```
      @@ -3552,8 +3556,8 @@ mkDupableContWithDmds env dmds
               --              let a = ...arg...
               --              in [...hole...] a
               -- NB: sc_dup /= OkToDup; that is caught earlier by contIsDupable
      -    do  { let (dmd:_) = dmds   -- Never fails
      -        ; (floats1, cont') <- mkDupableContWithDmds env dmds cont
      +    do  { let (dmd:cont_dmds) = dmds   -- Never fails
      +        ; (floats1, cont') <- mkDupableContWithDmds env cont_dmds cont
               ; let env' = env `setInScopeFromF` floats1
               ; (_, se', arg') <- simplArg env' dup se arg
               ; (let_floats2, arg'') <- makeTrivial env NotTopLevel dmd (fsLit "karg") arg'
      ```
      Ticket #23184 is a report of the bug that this diff fixes.
      0077cb22
  31. Mar 30, 2023
  32. Mar 21, 2023
  33. Mar 03, 2023
  34. Feb 28, 2023
Loading