[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: Reduce parser allocations in allocateCommentsP

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Mon Feb 5 17:38:17 UTC 2024



Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
0df8ce27 by Vladislav Zavialov at 2024-02-04T03:55:14-05:00
Reduce parser allocations in allocateCommentsP

In the most common case, the comment queue is empty, so we can skip the
work of processing it. This reduces allocations by about 10% in the
parsing001 test.

Metric Decrease:
    MultiLayerModulesRecomp
    parsing001

- - - - -
f74d2b35 by Ben Gamari at 2024-02-05T09:51:32+00:00
base: Cleanup whitespace in cbits

- - - - -
97671727 by Ben Gamari at 2024-02-05T12:23:10+00:00
Move `base` to `ghc-internal`

Here we move a good deal of the implementation of `base` into a new
package, `ghc-internal` such that it can be evolved independently
from the user-visible interfaces of `base`.

While we want to isolate implementation from interfaces, naturally, we
would like to avoid turning `base` into a mere set of module re-exports.
However, this is a non-trivial undertaking for a variety of reasons:

 * `base` contains numerous known-key and wired-in things, requiring
   corresponding changes in the compiler

 * `base` contains a significant amount of C code and corresponding
   autoconf logic, which is very fragile and difficult to break apart

 * `base` has numerous import cycles, which are currently dealt with via
   carefully balanced `hs-boot` files

 * We must not break existing users

To accomplish this migration, I tried the following approaches:

* [Split-GHC.Base]: Break apart the GHC.Base knot to allow incremental
  migration of modules into ghc-internal: this knot is simply too
  intertwined to be easily pulled apart, especially given the rather
  tricky import cycles that it contains)

* [Move-Core]: Moving the "core" connected component of base (roughly
  150 modules) into ghc-internal. While the Haskell side of this seems
  tractable, the C dependencies are very subtle to break apart.

* [Move-Incrementally]:

  1. Move all of base into ghc-internal
  2. Examine the module structure and begin moving obvious modules (e.g.
     leaves of the import graph) back into base
  3. Examine the modules remaining in ghc-internal, refactor as necessary
     to facilitate further moves
  4. Go to (2) iterate until the cost/benefit of further moves is
     insufficient to justify continuing
  5. Rename the modules moved into ghc-internal to ensure that they don't
     overlap with those in base
  6. For each module moved into ghc-internal, add a shim module to base
     with the declarations which should be exposed and any requisite
     Haddocks (thus guaranteeing that base will be insulated from changes
     in the export lists of modules in ghc-internal

Here I am using the [Move-Incrementally] approach, which is empirically
the least painful of the unpleasant options above

Bumps haddock submodule.

Metric Decrease:
    haddock.Cabal
    haddock.base
Metric Increase:
    MultiComponentModulesRecomp
    T16875

- - - - -
34a360e0 by Simon Peyton Jones at 2024-02-05T12:38:07-05:00
Stop dropping a case whose binder is demanded

This MR fixes #24251.

See Note [Case-to-let for strictly-used binders]
in GHC.Core.Opt.Simplify.Iteration, plus #24251, for
lots of discussion.

Final Nofib changes over 0.1%:
+-----------------------------------------
|        imaginary/digits-of-e2    -2.16%
|                imaginary/rfib    -0.15%
|                    real/fluid    -0.10%
|                   real/gamteb    -1.47%
|                       real/gg    -0.20%
|                 real/maillist    +0.19%
|                      real/pic    -0.23%
|                      real/scs    -0.43%
|               shootout/n-body    -0.41%
|        shootout/spectral-norm    -0.12%
+========================================
|                     geom mean    -0.05%

Pleasingly, overall executable size is down by just over 1%.

Compile times (in perf/compiler) wobble around a bit +/- 0.5%, but the
geometric mean is -0.1% which seems good.

- - - - -
ac5c3e4a by Simon Peyton Jones at 2024-02-05T12:38:08-05:00
Add Note [Bangs in Integer functions]

...to document the bangs in the functions in GHC.Num.Integer

- - - - -


30 changed files:

- .gitignore
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/StgToJS/Rts/Rts.hs
- compiler/GHC/Unit/Types.hs
- configure.ac
- libraries/base/base.cabal
- libraries/base/src/Control/Applicative.hs
- libraries/base/src/Control/Concurrent.hs
- libraries/base/src/Data/Complex.hs
- libraries/base/src/Data/Semigroup.hs
- + libraries/base/src/Dummy.hs
- libraries/base/src/System/CPUTime/Posix/Times.hsc
- libraries/ghc-bignum/src/GHC/Num/Integer.hs
- libraries/base/.authorspellings → libraries/ghc-internal/.authorspellings
- libraries/base/.gitignore → libraries/ghc-internal/.gitignore
- libraries/base/.hlint.yaml → libraries/ghc-internal/.hlint.yaml
- libraries/ghc-internal/LICENSE
- libraries/base/Setup.hs → libraries/ghc-internal/Setup.hs
- libraries/base/aclocal.m4 → libraries/ghc-internal/aclocal.m4
- libraries/base/cbits/CastFloatWord.cmm → libraries/ghc-internal/cbits/CastFloatWord.cmm
- libraries/base/cbits/DarwinUtils.c → libraries/ghc-internal/cbits/DarwinUtils.c
- libraries/base/cbits/IOutils.c → libraries/ghc-internal/cbits/IOutils.c
- libraries/base/cbits/PrelIOUtils.c → libraries/ghc-internal/cbits/PrelIOUtils.c
- libraries/base/cbits/SetEnv.c → libraries/ghc-internal/cbits/SetEnv.c
- libraries/base/cbits/StackCloningDecoding.cmm → libraries/ghc-internal/cbits/StackCloningDecoding.cmm
- libraries/base/cbits/Win32Utils.c → libraries/ghc-internal/cbits/Win32Utils.c


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8811b8040d71fec1be90f4c84517e1e8f2f1613c...ac5c3e4a2e5b1cdcefd1c051437211539b73b3c8

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8811b8040d71fec1be90f4c84517e1e8f2f1613c...ac5c3e4a2e5b1cdcefd1c051437211539b73b3c8
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240205/ae660b3d/attachment-0001.html>


More information about the ghc-commits mailing list