1. 10 Jun, 2021 6 commits
    • Simon Peyton Jones's avatar
      Fix INLINE pragmas in desugarer · 3d5cb335
      Simon Peyton Jones authored
      In #19969 we discovered that GHC has has a bug *forever* that means it
      sometimes essentially discarded INLINE pragams.  This happened when you have
      * Two more more mutually recursive functions
      * Some of which (presumably not all!) have an INLINE pragma
      * Completely monomorphic.
      This hits a particular case in GHC.HsToCore.Binds.dsAbsBinds, which was
      simply wrong -- it put the INLINE pragma on the wrong binder.
      This patch fixes the bug, rather easily, by adjusting the
      no-tyvar, no-dict case of GHC.HsToCore.Binds.dsAbsBinds.
      I also discovered that the GHC.Core.Opt.Pipeline.shortOutIndirections
      was not doing a good job for
          {-# INLINE lcl_id #-}
          lcl_id = BIG
          gbl_id = lcl_id
      Here we want to transfer the stable unfolding to gbl_id (we do), but
      we also want to remove it from lcl_id (we were not doing that).
      Otherwise both Ids have large stable unfoldings.  Easily fixed.
      Note [Transferring IdInfo] explains.
    • sheaf's avatar
      Reword: representation instead of levity · 472c2bf0
      sheaf authored
      fixes #19756, updates haddock submodule
    • Sylvain Henry's avatar
      Fix redundant import · 61c51c00
      Sylvain Henry authored
    • Matthew Pickering's avatar
      Add (broken) test for #19966 · fb6b6379
      Matthew Pickering authored
    • Xia Li-yao's avatar
    • Simon Peyton Jones's avatar
      Do not add unfoldings to lambda-binders · f4a5e30e
      Simon Peyton Jones authored
      For reasons described in GHC.Core.Opt.Simplify
      Historical Note [Case binders and join points],
      we used to keep a Core unfolding in one of the lambda-binders
      for a join point.  But this was always a gross hack -- it's
      very odd to have an unfolding in a lambda binder, that refers to
      earlier lambda binders.
      The hack bit us in various ways:
      * Most seriously, it is incompatible with linear types in Core.
      * It complicated demand analysis, and could worsen results
      * It required extra care in the simplifier (simplLamBinder)
      * It complicated !5641 (look for "join binder unfoldings")
      So this patch just removes the hack.  Happily, doind so turned out to
      have no effect on performance.
  2. 09 Jun, 2021 2 commits
  3. 08 Jun, 2021 1 commit
  4. 07 Jun, 2021 5 commits
    • Ryan Scott's avatar
      Introduce `hsExprType :: HsExpr GhcTc -> Type` in the new module · 7ea3b7eb
      Ryan Scott authored
      The existing `hsPatType`, `hsLPatType` and `hsLitType` functions have also been
      moved to this module
      This is a less ambitious take on the same problem that !2182 and !3866
      attempt to solve. Rather than have the `hsExprType` function attempt to
      efficiently compute the `Type` of every subexpression in an `HsExpr`, this
      simply computes the overall `Type` of a single `HsExpr`.
      - Explicitly forbids the `SplicePat` `HsIPVar`, `HsBracket`, `HsRnBracketOut`
        and `HsTcBracketOut` constructors during the typechecking phase by using
        `Void` as the TTG extension field
      - Also introduces `dataConCantHappen` as a domain specific alternative to `absurd`
        to handle cases where the TTG extension points forbid a constructor.
      - Turns HIE file generation into a pure function that doesn't need access to the
        `DsM` monad to compute types, but uses `hsExprType` instead.
      - Computes a few more types during HIE file generation
      - Makes GHCi's `:...
    • vdukhovni's avatar
      Small ZipList optimisation · 9e724f6e
      vdukhovni authored
      In (<|>) for ZipList, avoid processing the first argument twice (both as first
      argument of (++) and for its length in drop count of the second argument).
      Previously, the entire first argument was forced into memory, now (<|>) can run
      in constant space even with long inputs.
    • Sylvain Henry's avatar
      Bump haddock submodule · 40c0f67f
      Sylvain Henry authored
    • Sylvain Henry's avatar
      Parser: make less DynFlags dependent · 3a90814f
      Sylvain Henry authored
      This is an attempt at reducing the number of dependencies of the Parser
      (as reported by CountParserDeps). Modules in GHC.Parser.* don't import
      GHC.Driver.Session directly anymore.
      Sadly some GHC.Driver.* modules are still transitively imported and the
      number of dependencies didn't decrease. But it's a step in the right
    • Sylvain Henry's avatar
      Make Logger independent of DynFlags · 4dc681c7
      Sylvain Henry authored
      Introduce LogFlags as a independent subset of DynFlags used for logging.
      As a consequence in many places we don't have to pass both Logger and
      DynFlags anymore.
      The main reason for this refactoring is that I want to refactor the
      systools interfaces: for now many systools functions use DynFlags both
      to use the Logger and to fetch their parameters (e.g. ldInputs for the
      linker). I'm interested in refactoring the way they fetch their
      parameters (i.e. use dedicated XxxOpts data types instead of DynFlags)
      for #19877. But if I did this refactoring before refactoring the Logger,
      we would have duplicate parameters (e.g. ldInputs from DynFlags and
      linkerInputs from LinkerOpts). Hence this patch first.
      Some flags don't really belong to LogFlags because they are subsystem
      specific (e.g. most DumpFlags). For example -ddump-asm should better be
      passed in NCGConfig somehow. This patch doesn't fix this tight coupling:
      the dump flags are part of the UI but they are passed all the way...
  5. 05 Jun, 2021 15 commits
    • Ben Gamari's avatar
      testsuite: Fix Note style · 5e1a2244
      Ben Gamari authored
    • Ben Gamari's avatar
      testsuite: Eliminate fragility of ioprof · 3e343292
      Ben Gamari authored
      As noted in #10037, the `ioprof` test would change its stderr output
      (specifically the stacktrace produced by `error`) depending upon
      optimisation level. As the `error` backtrace is not the point of this
      test, we now ignore the `stderr` output.
    • Simon Peyton Jones's avatar
      Drop absent bindings in worker/wrapper · 34424b9d
      Simon Peyton Jones authored
      Consider this (from #19824)
         let t = ...big...
         in ...(f t x)...
      were `f` ignores its first argument.  With luck f's wrapper will inline
      thereby dropping `t`, but maybe not: the arguments to f all look boring.
      So we pre-empt the problem by replacing t's RHS with an absent filler
      during w/w.  Simple and effective.
      The main payload is the new `isAbsDmd` case in `tryWw`, but there are
      some other minor refactorings:
      * To implment this I had to refactor `mk_absent_let` to
        `mkAbsentFiller`, which can be called from `tryWW`.
      * wwExpr took both WwOpts and DynFlags which seems silly.  I combined
        them into one.
      * I renamed the historical mkInineRule to mkWrapperUnfolding
    • Simon Peyton Jones's avatar
      Re-do rubbish literals · 52a524f7
      Simon Peyton Jones authored
      As #19882 pointed out, we were simply doing rubbish literals wrong.
      (I'll refrain from explaining the wrong-ness here -- see the ticket.)
      This patch fixes it by adding a Type (of kind RuntimeRep) as field of
      LitRubbish, rather than [PrimRep].
      The Note [Rubbish literals] in GHC.Types.Literal explains the details.
    • Simon Peyton Jones's avatar
      Avoid useless w/w split, take 2 · ea9a4ef6
      Simon Peyton Jones authored
      This commit:
          commit c6faa42b
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Mon Mar 9 10:20:42 2020 +0000
          Avoid useless w/w split
          This patch is just a tidy-up for the post-strictness-analysis
          worker wrapper split.  Consider
             f x = x
          Strictnesss analysis does not lead to a w/w split, so the
          obvious thing is to leave it 100% alone.  But actually, because
          the RHS is small, we ended up adding a StableUnfolding for it.
          There is some reason to do this if we choose /not/ do to w/w
          on the grounds that the function is small.  See
          Note [Don't w/w inline small non-loop-breaker things]
          But there is no reason if we would not have done w/w anyway.
          This patch just moves the conditional to later.  Easy.
      turns out to have a bug in it.  Instead of /moving/ the conditional,
      I /duplicated/ it.  Then in a subsequent unrelated tidy-up
      (087ac4eb) I removed the second (redundant) test!
      This patch does what I originally intended.
      There is also a small refactoring in GHC.Core.Unfold, to make the
      code clearer, but with no change in behaviour.
      It does, however, have a generally good effect on compile times,
      because we aren't dealing with so many silly stable unfoldings.
      Here are the non-zero changes:
      Metrics: compile_time/bytes allocated
                           Test    Metric         value     New value Change
       ManyAlternatives(normal) ghc/alloc   791969344.0   792665048.0  +0.1%
       ManyConstructors(normal) ghc/alloc  4351126824.0  4358303528.0  +0.2%
              PmSeriesG(normal) ghc/alloc    50362552.0    50482208.0  +0.2%
              PmSeriesS(normal) ghc/alloc    63733024.0    63619912.0  -0.2%
                 T10421(normal) ghc/alloc   121224624.0   119695448.0  -1.3% GOOD
                T10421a(normal) ghc/alloc    85256392.0    83714224.0  -1.8%
                 T10547(normal) ghc/alloc    29253072.0    29258256.0  +0.0%
                 T10858(normal) ghc/alloc   189343152.0   187972328.0  -0.7%
                 T11195(normal) ghc/alloc   281208248.0   279727584.0  -0.5%
                 T11276(normal) ghc/alloc   141966952.0   142046224.0  +0.1%
                T11303b(normal) ghc/alloc    46228360.0    46259024.0  +0.1%
                 T11545(normal) ghc/alloc  2663128768.0  2667412656.0  +0.2%
                 T11822(normal) ghc/alloc   138686944.0   138760176.0  +0.1%
                 T12227(normal) ghc/alloc   482836000.0   475421056.0  -1.5% GOOD
                 T12234(optasm) ghc/alloc    60710520.0    60781808.0  +0.1%
                 T12425(optasm) ghc/alloc   104089000.0   104022424.0  -0.1%
                 T12545(normal) ghc/alloc  1711759416.0  1705711528.0  -0.4%
                 T12707(normal) ghc/alloc   991541120.0   991921776.0  +0.0%
                 T13035(normal) ghc/alloc   108199872.0   108370704.0  +0.2%
                 T13056(optasm) ghc/alloc   414642544.0   412580384.0  -0.5%
                 T13253(normal) ghc/alloc   361701272.0   355838624.0  -1.6%
             T13253-spj(normal) ghc/alloc   157710168.0   157397768.0  -0.2%
                 T13379(normal) ghc/alloc   370984400.0   371345888.0  +0.1%
                 T13701(normal) ghc/alloc  2439764144.0  2441351984.0  +0.1%
                   T14052(ghci) ghc/alloc  2154090896.0  2156671400.0  +0.1%
                 T15164(normal) ghc/alloc  1478517688.0  1440317696.0  -2.6% GOOD
                 T15630(normal) ghc/alloc   178053912.0   172489808.0  -3.1%
                 T16577(normal) ghc/alloc  7859948896.0  7854524080.0  -0.1%
                 T17516(normal) ghc/alloc  1271520128.0  1202096488.0  -5.5% GOOD
                 T17836(normal) ghc/alloc  1123320632.0  1123922480.0  +0.1%
                T17836b(normal) ghc/alloc    54526280.0    54576776.0  +0.1%
                T17977b(normal) ghc/alloc    42706752.0    42730544.0  +0.1%
                 T18140(normal) ghc/alloc   108834568.0   108693816.0  -0.1%
                 T18223(normal) ghc/alloc  5539629264.0  5579500872.0  +0.7%
                 T18304(normal) ghc/alloc    97589720.0    97196944.0  -0.4%
                 T18478(normal) ghc/alloc   770755472.0   771232888.0  +0.1%
                T18698a(normal) ghc/alloc   408691160.0   374364992.0  -8.4% GOOD
                T18698b(normal) ghc/alloc   492419768.0   458809408.0  -6.8% GOOD
                 T18923(normal) ghc/alloc    72177032.0    71368824.0  -1.1%
                  T1969(normal) ghc/alloc   803523496.0   804655112.0  +0.1%
                  T3064(normal) ghc/alloc   198411784.0   198608512.0  +0.1%
                  T4801(normal) ghc/alloc   312416688.0   312874976.0  +0.1%
               T5321Fun(normal) ghc/alloc   325230680.0   325474448.0  +0.1%
                  T5631(normal) ghc/alloc   592064448.0   593518968.0  +0.2%
                  T5837(normal) ghc/alloc    37691496.0    37710904.0  +0.1%
                   T783(normal) ghc/alloc   404629536.0   405064432.0  +0.1%
                  T9020(optasm) ghc/alloc   266004608.0   266375592.0  +0.1%
                  T9198(normal) ghc/alloc    49221336.0    49268648.0  +0.1%
                  T9233(normal) ghc/alloc   913464984.0   742680256.0 -18.7% GOOD
                  T9675(optasm) ghc/alloc   552296608.0   466322000.0 -15.6% GOOD
                 T9872a(normal) ghc/alloc  1789910616.0  1793924472.0  +0.2%
                 T9872b(normal) ghc/alloc  2315141376.0  2310338056.0  -0.2%
                 T9872c(normal) ghc/alloc  1840422424.0  1841567224.0  +0.1%
                 T9872d(normal) ghc/alloc   556713248.0   556838432.0  +0.0%
                  T9961(normal) ghc/alloc   383809160.0   384601600.0  +0.2%
                  WWRec(normal) ghc/alloc   773751272.0   753949608.0  -2.6% GOOD
      Residency goes down too:
      Metrics: compile_time/max_bytes_used
                 Test  Metric         value     New value Change
       T10370(optasm) ghc/max    42058448.0    39481672.0  -6.1%
       T11545(normal) ghc/max    43641392.0    43634752.0  -0.0%
       T15304(normal) ghc/max    29895824.0    29439032.0  -1.5%
       T15630(normal) ghc/max     8822568.0     8772328.0  -0.6%
      T18698a(normal) ghc/max    13882536.0    13787112.0  -0.7%
      T18698b(normal) ghc/max    14714112.0    13836408.0  -6.0%
        T1969(normal) ghc/max    24724128.0    24733496.0  +0.0%
        T3064(normal) ghc/max    14041152.0    14034768.0  -0.0%
        T3294(normal) ghc/max    32769248.0    32760312.0  -0.0%
        T9630(normal) ghc/max    41605120.0    41572184.0  -0.1%
        T9675(optasm) ghc/max    18652296.0    17253480.0  -7.5%
      Metric Decrease:
      Metric Increase:
    • Shayne Fletcher's avatar
      Countdeps: Strictly documentation markup fixes · cced9454
      Shayne Fletcher authored
      [ci skip]
    • Moritz Angermann's avatar
    • Moritz Angermann's avatar
      [testsuite] fix T13702 with clang · 4db2d44c
      Moritz Angermann authored
    • Moritz Angermann's avatar
      [ci] force CC=clang for aarch64-linux · a1fed3a5
      Moritz Angermann authored
    • Moritz Angermann's avatar
      [ci] no docs for aarch64-linux-llvm · 1b2f894f
      Moritz Angermann authored
    • Moritz Angermann's avatar
      [ci] -llvm with --way=llvm · db1e07f1
      Moritz Angermann authored
    • Moritz Angermann's avatar
      Adds AArch64 Native Code Generator · 3b1aa7db
      Moritz Angermann authored
      In which we add a new code generator to the Glasgow Haskell
      Compiler. This codegen supports ELF and Mach-O targets, thus covering
      Linux, macOS, and BSDs in principle.  It was tested only on macOS and
      Linux.  The NCG follows a similar structure as the other native code
      generators we already have, and should therfore be realtively easy to
      It supports most of the features required for a proper native code
      generator, but does not claim to be perfect or fully optimised.  There
      are still opportunities for optimisations.
      Metric Decrease:
    • Richard Eisenberg's avatar
      Fix #19682 by breaking cycles in Deriveds · 8c90e6c7
      Richard Eisenberg authored
      This commit expands the old Note [Type variable cycles in Givens] to apply
      as well to Deriveds. See the Note for details and examples. This fixes a
      regression introduced by my earlier commit that killed off the flattener in
      favor of the rewriter.
      A few other things happened along the way:
      * unifyTest was renamed to touchabilityTest, because that's what it does.
      * isInsolubleOccursCheck was folded into checkTypeEq, which does much of the
        same work. To get this to work out, though, we need to keep more careful
        track of what errors we spot in checkTypeEq, and so CheckTyEqResult has
        become rather more glorious.
      * A redundant Note or two was eliminated.
      * Kill off occCheckForErrors; due to Note [Rewriting synonyms], the
        extra occCheckExpand here is always redundant.
      * Store blocked equalities separately from other inerts; less stuff
        to look through when kicking out.
      Close #19682.
      test case: typecheck/should_compile/T19682{,b}
    • Sylvain Henry's avatar
    • Shayne Fletcher's avatar
      Make 'count-deps' a ghc/util standalone program · 1713cbb0
      Shayne Fletcher authored
      - Move 'count-deps' into 'ghc/utils' so that it can be called standalone.
      - Move 'testsuite/tests/parser/should_run/' tests 'CountParserDeps' and
      'CountAstDeps' to 'testsuite/tests/count-deps' and reimplement in terms
      of calling the utility
      - Document how to use 'count-deps' in 'ghc/utils/count-deps/README'
  6. 04 Jun, 2021 5 commits
  7. 03 Jun, 2021 5 commits
    • Roland Senn's avatar
      Follow up #12449: Improve function `Inspect.hs:check2` · 7a05185a
      Roland Senn authored
      * Add a Note to clarify RttiTypes.
      * Don't call `quantifyType` at all the call sites of `check2`.
      * Simplyfy arguments of functions `Inspect.hs:check1` and `Inspect.hs:check2`.
        - `check1` only uses the two lists of type variables, but not the types.
        - `check2` only uses the two types, but not the lists of type variables.
      * In `Inspect.hs:check2` send only the tau part of the type to `tcSplitTyConApp_maybe`.
    • Alfredo Di Napoli's avatar
      Port HsToCore messages to new infrastructure · d5b89ed4
      Alfredo Di Napoli authored
      This commit converts a bunch of HsToCore (Ds) messages to use the new
      GHC's diagnostic message infrastructure. In particular the DsMessage
      type has been expanded with a lot of type constructors, each
      encapsulating a particular error and warning emitted during desugaring.
      Due to the fact that levity polymorphism checking can happen both at the
      Ds and at the TcRn level, a new `TcLevityCheckDsMessage` constructor has
      been added to the `TcRnMessage` type.
    • Matthew Pickering's avatar
      Driver Rework Patch · 25977ab5
      Matthew Pickering authored
      This patch comprises of four different but closely related ideas. The
      net result is fixing a large number of open issues with the driver
      whilst making it simpler to understand.
      1. Use the hash of the source file to determine whether the source file
      has changed or not. This makes the recompilation checking more robust to
      modern build systems which are liable to copy files around changing
      their modification times.
      2. Remove the concept of a "stable module", a stable module was one
      where the object file was older than the source file, and all transitive
      dependencies were also stable. Now we don't rely on the modification
      time of the source file, the notion of stability is moot.
      3. Fix TH/plugin recompilation after the removal of stable modules. The
      TH recompilation check used to rely on stable modules. Now there is a
      uniform and simple way, we directly track the linkables which were
      loaded into the interpreter whilst compiling a module. This is an
      over-approximation but more robust wrt package dependencies changing.
      4. Fix recompilation checking for dynamic object files. Now we actually
      check if the dynamic object file exists when compiling with -dynamic-too
      Fixes #19774 #19771 #19758 #17434 #11556 #9121 #8211 #16495 #7277 #16093
    • Shayne Fletcher's avatar
      CountDeps: print graph of module dependencies in dot format · 79d12d34
      Shayne Fletcher authored
      The tests `CountParserDeps.hs` and `CountAstDeps.hs` are implemented
      by calling `CountDeps`. In this MR, `CountDeps.printDeps` is updated
      such tat by uncommenting a line, you can print a module's dependency
      graph showing what includes what. The output is in a format suitable
      for use with graphviz.
    • Sebastian Graf's avatar
      WW: Mark absent errors as diverging again · b585aff0
      Sebastian Graf authored
      As the now historic part of `NOTE [aBSENT_ERROR_ID]` explains, we used to have
      `exprIsHNF` respond True to `absentError` and give it a non-bottoming demand
      signature, in order to perform case-to-let on certain `case`s we used to emit
      that scrutinised `absentError` (Urgh).
      What changed, why don't we emit these questionable absent errors anymore?
      The absent errors in question filled in for binders that would end up in
      strict fields after being seq'd. Apparently, the old strictness analyser would
      give these binders an absent demand, but today we give them head-strict demand
      `1A` and thus don't replace with absent errors at all.
      This fixes items (1) and (2) of #19853.
  8. 02 Jun, 2021 1 commit
    • Matthew Pickering's avatar
      Fix infinite looping in hptSomeModulesBelow · b66cf8ad
      Matthew Pickering authored
      When compiling Agda we entered into an infinite loop as the stopping
      condition was a bit wrong in hptSomeModulesBelow.
      The bad situation was something like
      * We would see module A (NotBoot) and follow it dependencies
      * Later on we would encounter A (Boot) and follow it's dependencies,
        because the lookup would not match A (NotBoot) and A (IsBoot)
      * Somewhere in A (Boot)s dependencies, A (Boot) would appear again and
        lead us into an infinite loop.
      Now the state marks whether we have been both variants (IsBoot and
      NotBoot) so we don't follow dependencies for A (Boot) many times.