1. 01 Aug, 2020 1 commit
  2. 31 Jul, 2020 5 commits
  3. 30 Jul, 2020 6 commits
    • Simon Peyton Jones's avatar
      Add two bangs to improve perf of flattening · 9f71f697
      Simon Peyton Jones authored
      This tiny patch improves the compile time of flatten-heavy
      programs by 1-2%, by adding two bangs.
      
      Addresses (somewhat) #18502
      
      This reduces allocation by
         T9872b   -1.1%
         T9872d   -3.3%
      
         T5321Fun -0.2%
         T5631    -0.2%
         T5837    +0.1%
         T6048    +0.1%
      
      Metric Decrease:
          T9872b
          T9872d
      9f71f697
    • Simon Peyton Jones's avatar
      Remove an incorrect WARN in extendLocalRdrEnv · ebe2cf45
      Simon Peyton Jones authored
      I noticed this warning going off, and discovered that it's
      really fine.  This small patch removes the warning, and docments
      what is going on.
      ebe2cf45
    • Ryan Scott's avatar
      Don't mark closed type family equations as occurrences · d47324ce
      Ryan Scott authored
      Previously, `rnFamInstEqn` would mark the name of the type/data
      family used in an equation as an occurrence, regardless of what sort
      of family it is. Most of the time, this is the correct thing to do.
      The exception is closed type families, whose equations constitute its
      definition and therefore should not be marked as occurrences.
      Overzealously counting the equations of a closed type family as
      occurrences can cause certain warnings to not be emitted, as observed
      in #18470.  See `Note [Type family equations and occurrences]` in
      `GHC.Rename.Module` for the full story.
      
      This fixes #18470 with a little bit of extra-casing in
      `rnFamInstEqn`. To accomplish this, I added an extra
      `ClosedTyFamInfo` field to the `NonAssocTyFamEqn` constructor of
      `AssocTyFamInfo` and refactored the relevant call sites accordingly
      so that this information is propagated to `rnFamInstEqn`.
      
      While I was in town, I moved `wrongTyFamName`, which checks that the
      name of a closed type family matches the name in an equation for that
      family, from the renamer to the typechecker to avoid the need for an
      `ASSERT`. As an added bonus, this lets us simplify the details of
      `ClosedTyFamInfo` a bit.
      d47324ce
    • Ryan Scott's avatar
      Clean up the inferred type variable restriction · 01c948eb
      Ryan Scott authored
      This patch primarily:
      
      * Documents `checkInferredVars` (previously called
        `check_inferred_vars`) more carefully. This is the
        function which throws an error message if a user quantifies an
        inferred type variable in a place where specificity cannot be
        observed. See `Note [Unobservably inferred type variables]` in
        `GHC.Rename.HsType`.
      
        Note that I now invoke `checkInferredVars` _alongside_
        `rnHsSigType`, `rnHsWcSigType`, etc. rather than doing so _inside_
        of these functions. This results in slightly more call sites for
        `checkInferredVars`, but it makes it much easier to enumerate the
        spots where the inferred type variable restriction comes into
        effect.
      * Removes the inferred type variable restriction for default method
        type signatures, per the discussion in #18432. As a result, this
        patch fixes #18432.
      
      Along the way, I performed some various cleanup:
      
      * I moved `no_nested_foralls_contexts_err` into `GHC.Rename.Utils`
        (under the new name `noNestedForallsContextsErr`), since it now
        needs to be invoked from multiple modules. I also added a helper
        function `addNoNestedForallsContextsErr` that throws the error
        message after producing it, as this is a common idiom.
      * In order to ensure that users cannot sneak inferred type variables
        into `SPECIALISE instance` pragmas by way of nested `forall`s, I
        now invoke `addNoNestedForallsContextsErr` when renaming
        `SPECIALISE instance` pragmas, much like when we rename normal
        instance declarations. (This probably should have originally been
        done as a part of the fix for #18240, but this task was somehow
        overlooked.) As a result, this patch fixes #18455 as a side effect.
      01c948eb
    • cgibbard's avatar
      Add haddock comment for unfilteredEdges · 502de556
      cgibbard authored
      and move the note about drop_hs_boot_nodes into it.
      502de556
    • John Ericson's avatar
      For `-fkeep-going` do not duplicate dependency edge code · 6c68a842
      John Ericson authored
      We now compute the deps for `-fkeep-going` the same way that the
      original graph calculates them, so the edges are correct. Upsweep really
      ought to take the graph rather than a topological sort so we are never
      recalculating anything, but at least things are recaluclated
      consistently now.
      6c68a842
  4. 29 Jul, 2020 11 commits
  5. 28 Jul, 2020 9 commits
    • Peter Trommler's avatar
      f305bbfd
    • Sylvain Henry's avatar
      Bignum: add support for negative shifts (fix #18499) · 6ee07b49
      Sylvain Henry authored
      shiftR/shiftL support negative arguments despite Haskell 2010 report
      saying otherwise. We explicitly test for negative values which is bad
      (it gets in the way of constant folding, etc.). Anyway, for consistency
      we fix Bits instancesof Integer/Natural.
      6ee07b49
    • Simon Peyton Jones's avatar
      This patch addresses the exponential blow-up in the simplifier. · 0bd60059
      Simon Peyton Jones authored
      Specifically:
        #13253 exponential inlining
        #10421 ditto
        #18140 strict constructors
        #18282 another nested-function call case
      
      This patch makes one really significant changes: change the way that
      mkDupableCont handles StrictArg.  The details are explained in
      GHC.Core.Opt.Simplify Note [Duplicating StrictArg].
      
      Specific changes
      
      * In mkDupableCont, when making auxiliary bindings for the other arguments
        of a call, add extra plumbing so that we don't forget the demand on them.
        Otherwise we haev to wait for another round of strictness analysis. But
        actually all the info is to hand.  This change affects:
        - Make the strictness list in ArgInfo be [Demand] instead of [Bool],
          and rename it to ai_dmds.
        - Add as_dmd to ValArg
        - Simplify.makeTrivial takes a Demand
        - mkDupableContWithDmds takes a [Demand]
      
      There are a number of other small changes
      
      1. For Ids that are used at most once in each branch of a case, make
         the occurrence analyser record the total number of syntactic
         occurrences.  Previously we recorded just OneBranch or
         MultipleBranches.
      
         I thought this was going to be useful, but I ended up barely
         using it; see Note [Note [Suppress exponential blowup] in
         GHC.Core.Opt.Simplify.Utils
      
         Actual changes:
           * See the occ_n_br field of OneOcc.
           * postInlineUnconditionally
      
      2. I found a small perf buglet in SetLevels; see the new
         function GHC.Core.Opt.SetLevels.hasFreeJoin
      
      3. Remove the sc_cci field of StrictArg.  I found I could get
         its information from the sc_fun field instead.  Less to get
         wrong!
      
      4. In ArgInfo, arrange that ai_dmds and ai_discs have a simpler
         invariant: they line up with the value arguments beyond ai_args
         This allowed a bit of nice refactoring; see isStrictArgInfo,
         lazyArgcontext, strictArgContext
      
      There is virtually no difference in nofib. (The runtime numbers
      are bogus -- I tried a few manually.)
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                  fft          +0.0%     -2.0%    -48.3%    -49.4%      0.0%
           multiplier          +0.0%     -2.2%    -50.3%    -50.9%      0.0%
      --------------------------------------------------------------------------------
                  Min          -0.4%     -2.2%    -59.2%    -60.4%      0.0%
                  Max          +0.0%     +0.1%     +3.3%     +4.9%      0.0%
       Geometric Mean          +0.0%     -0.0%    -33.2%    -34.3%     -0.0%
      
      Test T18282 is an existing example of these deeply-nested strict calls.
      We get a big decrease in compile time (-85%) because so much less
      inlining takes place.
      
      Metric Decrease:
          T18282
      0bd60059
    • Ben Gamari's avatar
      gitlab-ci: Bump bootstrap compiler to 8.8.4 · 0a815cea
      Ben Gamari authored
      Hopefully this will make the Windows jobs a bit more reliable.
      0a815cea
    • Ben Gamari's avatar
      gitlab-ci: Ensure that Hadrian jobs don't download artifacts · 57aca6bb
      Ben Gamari authored
      Previously the Hadrian jobs had the default dependencies, meaning that
      they would download artifacts from all jobs of earlier stages. This is
      unneccessary.
      57aca6bb
    • Simon Peyton Jones's avatar
      Eta-expand the Simplifier monad · 3d345c96
      Simon Peyton Jones authored
      This patch eta-expands the Simplifier's monad, using the method
      explained in GHC.Core.Unify Note [The one-shot state monad trick].
      It's part of the exta-expansion programme in #18202.
      
      It's a tiny patch, but is worth a 1-2% reduction in bytes-allocated
      by the compiler.  Here's the list, based on the compiler-performance
      tests in perf/compiler:
      
                          Reduction in bytes allocated
         T10858(normal)      -0.7%
         T12425(optasm)      -1.3%
         T13056(optasm)      -1.8%
         T14683(normal)      -1.1%
         T15164(normal)      -1.3%
         T15630(normal)      -1.4%
         T17516(normal)      -2.3%
         T18282(normal)      -1.6%
         T18304(normal)      -0.8%
         T1969(normal)       -0.6%
         T4801(normal)       -0.8%
         T5321FD(normal)     -0.7%
         T5321Fun(normal)    -0.5%
         T5642(normal)       -0.9%
         T6048(optasm)       -1.1%
         T9020(optasm)       -2.7%
         T9233(normal)       -0.7%
         T9675(optasm)       -0.5%
         T9961(normal)       -2.9%
         WWRec(normal)       -1.2%
      
      Metric Decrease:
          T12425
          T9020
          T9961
      3d345c96
    • Michalis Pardalos's avatar
      Use allocate, not ALLOC_PRIM_P for unpackClosure# · 47680cb7
      Michalis Pardalos authored
      ALLOC_PRIM_P fails for large closures, by directly using allocate
      we can handle closures which are larger than the block size.
      
      Fixes #12492
      47680cb7
    • Michalis Pardalos's avatar
      Add minimal test for #12492 · 6da73bbf
      Michalis Pardalos authored
      6da73bbf
    • Ben Gamari's avatar
      Drop 32-bit Windows support · aa054d32
      Ben Gamari authored
      As noted in #18487, we have reached the end of this road.
      aa054d32
  6. 27 Jul, 2020 3 commits
    • Vladislav Zavialov's avatar
      Refactor the parser a little · 6ff89c17
      Vladislav Zavialov authored
      * Create a dedicated production for type operators
      * Create a dedicated type for the UNPACK pragma
      * Remove an outdated part of Note [Parsing data constructors is hard]
      6ff89c17
    • leiftw's avatar
    • Vladislav Zavialov's avatar
      Improve NegativeLiterals (#18022, GHC Proposal #344) · aee45d9e
      Vladislav Zavialov authored
      Before this patch, NegativeLiterals used to parse x-1 as x (-1).
      
      This may not be what the user expects, and now it is fixed:
      x-1 is parsed as (-) x 1.
      
      We achieve this by the following requirement:
      
        * When lexing a negative literal,
          it must not be preceded by a 'closing token'.
      
      This also applies to unboxed literals, e.g. -1#.
      
      See GHC Proposal #229 for the definition of a closing token.
      
      A nice consequence of this change is that -XNegativeLiterals becomes a
      subset of -XLexicalNegation. In other words, enabling both of those
      extensions has the same effect as enabling -XLexicalNegation alone.
      aee45d9e
  7. 26 Jul, 2020 5 commits