1. 07 Jul, 2021 2 commits
    • Matthew Pickering's avatar
      driver: Add test for #12983 · 5a31abe3
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      This test has worked since 8.10.2 at least but was recently broken and
      is now working again after this patch.
      Closes #12983
    • Matthew Pickering's avatar
      driver: Convert runPipeline to use a free monad · 421beb3f
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      This patch converts the runPipeline function to be implemented in terms
      of a free monad rather than the previous CompPipeline.
      The advantages of this are three-fold:
      1. Different parts of the pipeline can return different results, the
      limits of runPipeline were being pushed already by !5555, this opens up
      futher fine-grainedism of the pipeline.
      2. The same mechanism can be extended to build-plan at the module level
      so the whole build plan can be expressed in terms of one computation
      which can then be treated uniformly.
      3. The pipeline monad can now be interpreted in different ways, for
      example, you may want to interpret the `TPhase` action into the monad
      for your own build system (such as shake). That bit will probably
      require a bit more work, but this is a step in the right directin.
      There are a few more modules containing useful functions for interacting
      with the pipelines.
      * GHC.Driver.Pipeline: Functions for building pipelines at a high-level
      * GHC.Driver.Pipeline.Execute: Functions for providing the default
      interpretation of TPhase, in terms of normal IO.
      * GHC.Driver.Pipeline.Phases: The home for TPhase, the typed phase data
      type which dictates what the phases are.
      * GHC.Driver.Pipeline.Monad: Definitions to do with the TPipelineClass
      and MonadUse class.
      Hooks consumers may notice the type of the `phaseHook` has got
      slightly more restrictive, you can now no longer control the
      continuation of the pipeline by returning the next phase to execute but
      only override individual phases. If this is a problem then please open
      an issue and we will work out a solution.
      Metric Decrease:
  2. 06 Jul, 2021 6 commits
    • Andreas Klebinger's avatar
      Fix #19889 - Invalid BMI2 instructions generated. · 6618008b
      Andreas Klebinger authored
      When arguments are 8 *or 16* bits wide, then truncate before/after
      and use the 32bit operation.
    • CSEdd's avatar
      Fix issue 20038 - Change 'variable' -> 'variables' · 17091114
      CSEdd authored and Marge Bot's avatar Marge Bot committed
    • Sylvain Henry's avatar
      Use target platform in guessOutputFile · 354ac99d
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
    • Ethan Kiang's avatar
      Pass '-x c++' and '-std=c++11' to `cc` for cpp files, in Hadrian · 4002bd1d
      Ethan Kiang authored and Marge Bot's avatar Marge Bot committed
      '-x c++' was found to be required on Darwin Clang 11 and 12.
      '-std=c++' was found to be needed on Clang 12 but not 11.
    • Fraser Tweedale's avatar
      Add test for executablePath · a4e742c5
      Fraser Tweedale authored and Marge Bot's avatar Marge Bot committed
    • Fraser Tweedale's avatar
      Implement improved "get executable path" query · 4b4c5e43
      Fraser Tweedale authored and Marge Bot's avatar Marge Bot committed
      System.Environment.getExecutablePath has some problems:
      - Some system-specific implementations throw an exception in some
        scenarios, e.g. when the executable file has been deleted
      - The Linux implementation succeeds but returns an invalid FilePath
        when the file has been deleted.
      - The fallback implementation returns argv[0] which is not
        necessarily an absolute path, and is subject to manipulation.
      - The documentation does not explain any of this.
      Breaking the getExecutablePath API or changing its behaviour is not
      an appealing direction.  So we will provide a new API.
      There are two facets to the problem of querying the executable path:
      1. Does the platform provide a reliable way to do it?  This is
         statically known.
      2. If so, is there a valid answer, and what is it?  This may vary,
         even over the runtime of a single process.
      Accordingly, the type of the new mechanism is:
        Maybe (IO (Maybe FilePath))
      This commit implements this mechanism, defining the query action for
      FreeBSD, Linux, macOS and Windows.
      Fixes: #10957
      Fixes: #12377
  3. 03 Jul, 2021 2 commits
    • Sebastian Graf's avatar
      Arity: Handle shadowing properly · 9b1d9cbf
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      In #20070, we noticed that `findRhsArity` copes badly with shadowing.
      A simple function like `g_123 x_123 = x_123`, where the labmda binder shadows,
      already regressed badly.
      Indeed, the whole `arityType` function wasn't thinking about shadowing *at all*.
      I rectified that and established the invariant that `ae_join` and `am_sigs`
      should always be disjoint. That entails deleting bindings from `ae_join`
      whenever we add something to `am_sigs` and vice versa, which would otherwise be
      a bug in the making.
      That *should* fix (but I don't want to close it) #20070.
    • Luite Stegeman's avatar
      Support unlifted datatypes in GHCi · 5e30451d
      Luite Stegeman authored and Marge Bot's avatar Marge Bot committed
      fixes #19628
  4. 02 Jul, 2021 5 commits
  5. 01 Jul, 2021 12 commits
  6. 29 Jun, 2021 3 commits
    • Matthew Pickering's avatar
      ci: Don't allow aarch64-darwin to fail · 2ce7c515
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      Part way to #20013
    • sheaf's avatar
      Use HsExpansion for overloaded list patterns · 4e9f58c7
      sheaf authored and Marge Bot's avatar Marge Bot committed
      Fixes #14380, #19997
    • Sebastian Graf's avatar
      Demand: Better representation (#19050) · b760c1f7
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      In #19050, we identified several ways in which we could make more illegal
      states irrepresentable. This patch introduces a few representation changes
      around `Demand` and `Card` with a better and earlier-failing API exported
      through pattern synonyms. Specifically,
      1. The old enum definition of `Card` led to severely bloated code of operations
         on it. I switched to a bit vector representation; much nicer overall IMO.
         See Note [Bit vector representation for Card].
      Most of the gripes with the old representation were related to where which kind
      of `Card` was allowed and the fact that it doesn't make sense for an absent or
      bottoming demand to carry a `SubDemand` that describes an evaluation context
      that is never realised.
      2. So I refactored the `Demand` representation so that it has two new data
         constructors for `AbsDmd` and `BotDmd`. The old `(:*)` data constructor
         becomes a pattern synonym which expands absent demands as needed, so that
         it still forms a complete match and a versatile builder. The new `Demand`
         data constructor now carries a `CardNonAbs` and only occurs in a very limited
         number of internal call sites.
      3. Wherever a full-blown `Card` might end up in a `CardNonAbs` field (like that
         of `D` or `Call`), I assert the consistency. When the smart builder of `(:*)`
         is called with an absent `Card`, I assert that the `SubDemand` is the same
         that we would expand to in the matcher.
      4. `Poly` now takes a `CardNonOnce` and encodes the previously noticed invariant
         that we never produce `Poly C_11` or `Poly C_01`. I made sure that we never
         construct a `Poly` with `C_11` or `C_01`.
      Fixes #19050.
      We lose a tiny bit of anal perf overall, probably because the new `Demand`
      definition can't be unboxed. The biggest loser is WWRec, where allocations go
      from 16MB to 26MB in DmdAnal, making up for a total increase of (merely) 1.6%.
      It's all within acceptance thresholds.
      There are even two ghc/alloc metric decreases. T11545 decreases by *67%*!
      Metric Decrease:
  7. 28 Jun, 2021 4 commits
  8. 27 Jun, 2021 6 commits
    • Matthew Pickering's avatar
      Revert "Make reallyUnsafePtrEquality# levity-polymorphic" · 469126b3
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      This reverts commit d1f59540.
      This commit breaks the build of unordered-containers
      [3 of 9] Compiling Data.HashMap.Internal.Array ( Data/HashMap/Internal/Array.hs, dist/build/Data/HashMap/Internal/Array.o, dist/build/Data/HashMap/Internal/Array.dyn_o )
      *** Parser [Data.HashMap.Internal.Array]:
      Parser [Data.HashMap.Internal.Array]: alloc=21043544 time=13.621
      *** Renamer/typechecker [Data.HashMap.Internal.Array]:
      Renamer/typechecker [Data.HashMap.Internal.Array]: alloc=151218672 time=187.083
      *** Desugar [Data.HashMap.Internal.Array]:
      ghc: panic! (the 'impossible' happened)
        GHC version 9.3.20210625:
      	expectJust splitFunTy
      CallStack (from HasCallStack):
        error, called at compiler/GHC/Data/Maybe.hs:68:27 in ghc:GHC.Data.Maybe
        expectJust, called at compiler/GHC/Core/Type.hs:1247:14 in ghc:GHC.Core.Type
      Revert containers submodule update
    • Sebastian Graf's avatar
      testsuite: Widen acceptance window of T12545 (#19414) · 43bbf4b2
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      In a sequel of #19414, I wrote a script that measures min and max allocation
      bounds of T12545 based on randomly modifying -dunique-increment. I got a spread
      of as much as 4.8%. But instead of widening the acceptance window further (to
      5%), I committed the script as part of this commit, so that false positive
      increases can easily be diagnosed by comparing min and max bounds to HEAD.
      Indeed, for !5814 we have seen T12545 go from -0.3% to 3.3% after a rebase.
      I made sure that the min and max bounds actually stayed the same.
      In the future, this kind of check can very easily be done in a matter of a
      minute. Maybe we should increase the acceptance threshold if we need to check
      often (leave a comment on #19414 if you had to check), but I've not been bitten
      by it for half a year, which seems OK.
      Metric Increase:
    • Sebastian Graf's avatar
      Inliner: Regard LitRubbish as TrivArg and not ConLike · b92479f9
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      Part of fixing #19766 required the emission of `LitRubbish` as absent filler in
      places where we used `absentError` before. In WWRec we have the situation that
      such bindings occur in the argument to functions. With `LitRubbish` we inlined
      those functions, because
       1. The absent binding was regarded as ConLike. So I fixed `exprIsHNFLike` to
          respond `False` to `LitRubbish`.
       2. The other source of inlining was that after inlining such an absent
          binding, `LitRubbish` itself was regarded `ValueArg` by `interestingArg`,
          leading to more inlining. It now responds `TrivArg` to `LitRubbish`.
      Fixes #20035.
      There's one slight 1.6% ghc/alloc regression left in T15164 that is due to an
      additional specialisation `$s$cget`. I've no idea why that happens; the Core
      output before is identical and has the call site that we specialise for.
      Metric Decrease:
    • Sebastian Graf's avatar
      Add regression test for #17819 · e69d070b
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      The only item left in #17819. Fixes #17819.
    • Sebastian Graf's avatar
      WorkWrap: Make mkWWstr and mkWWcpr generate fewer let bindings · 37472a10
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      In !5814 (comment 355144),
      Simon noted that `mkWWstr` and `mkWWcpr` could generate fewer let bindings and
      be implemented less indirectly by returning the rebuilt expressions directly, e.g. instead of
      f :: (Int, Int) -> Int
      f (x, y) = x+y
      f :: (Int, Int) -> Int
      f p = case p of (x, y) ->
            case x of I# x' ->
            case y of I# y' ->
            case $wf x' y' of r' ->
            let r = I# r' -- immediately returned
            in r
      f :: Int# -> Int# -> Int#
      $wf x' y' = let x = I# x' in   -- only used in p
                  let y = I# y' in   -- only used in p
                  let p = (x, y) in  -- only used in the App below
                  case (\(x,y) -> x+y) p of I# r' ->
      we know generate
      f :: (Int, Int) -> Int
      f p = case p of (x, y) ->
            case x of I# x' ->
            case y of I# y' ->
            case $wf x' y' of r' ->
            I# r' -- 1 fewer let
      f :: Int# -> Int# -> Int#
      $wf x' y' = case (\(x,y) -> x+y) (I# x, I# y) of I# r' -> -- 3 fewer lets
      Which is much nicer and makes it easier to comprehend the output of
      worker-wrapper pre-Simplification as well as puts less strain on the Simplifier.
      I had to drop support for #18983, but we found that it's broken anyway.
      Simon is working on a patch that provides a bit more justification.
    • Sebastian Graf's avatar
      WorkWrap: Remove mkWWargs (#19874) · eee498bf
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      `mkWWargs`'s job was pushing casts inwards and doing eta expansion to match
      the arity with the number of argument demands we w/w for.
      Nowadays, we use the Simplifier to eta expand to arity. In fact, in recent years
      we have even seen the eta expansion done by w/w as harmful, see Note [Don't eta
      expand in w/w]. If a function hasn't enough manifest lambdas, don't w/w it!
      What purpose does `mkWWargs` serve in this world? Not a great one, it turns out!
      I could remove it by pulling some important bits,
      notably Note [Freshen WW arguments] and Note [Join points and beta-redexes].
      Result: We reuse the freshened binder names of the wrapper in the
      worker where possible (see testuite changes), much nicer!
      In order to avoid scoping errors due to lambda-bound unfoldings in worker
      arguments, we zap those unfoldings now. In doing so, we fix #19766.
      Fixes #19874.