GitLab

Alan Zimmerman pushed to branch wip/az/exactprint-annotation-rationalisation at Glasgow Haskell Compiler / GHC

Commits:

c130188d

by Rodrigo Mesquita at 2026-08-15T06:29:53-04:00

loopImports: Don't dup ms_uid in summary imports

We were writing the ms_unitid of the mod summary with every single
import of that module

That complicated the code (as though the UnitId in that list could ever
be something else) and also allocates unnecessarily per every mod
import. Very slight allocation decrease measured locally in a few tests:
(MultiComponentModulesRecomp: -0.06%; MultiComponentModulesRecomp100: -0.05%)

Purely a clean up.

c71166a8

by Rodrigo Mesquita at 2026-08-15T06:29:53-04:00

downsweep: make control flow simpler and cache correct

This refactor extracts the control flow of downsweep into a single
function `dfsBuild`, which takes care of iteratively expanding and
traversing all nodes of the in-construction module graph necessary to
build a full `ModuleGraph`.

There are three levels of caching going on, all of which are necessary
to make sure we don't do repeated work (notably, NEVER summarise the
same module twice).

1. `dfsBuild` accumulates the final module graph and never revisits the
   same node of the module graph. Cache is keyed by the final
   `ModuleGraph`s `NodeKey`s.

2. For Module A in home-unit u1, each import in the list of imports
   needs to be *found* (call to `findImportedModuleWithIsBoot`): at this
   point, we only have the `ModuleName` of the import, not the `Module`.
   This *finding* is somewhat expensive, so we cache it as well
   (`ImportsCache`). The cache key is the home-unit to which the module
   belongs~[1], the import package qualifier, and the ModuleName.

   [1] Different home-units will have different package flags, which means
   potentially different `Module` resolution for the same `ModuleName`.

3. The most expensive operation we want to avoid is summarising a
   `Module` into a `ModSummary`, which notably involves parsing the
   module header from scratch.
   The third cache, in essence, maps a `Module` to its `ModSummary`
   (named `ModSummaryCache`). This cache upholds the invariant: we NEVER
   summarise the same module twice. In practice, the cache key is the
   Module's UnitId and the Source path; the reason is we need to
   distinguish between `.hs` and `.hs-boot` files, as their summaries
   will differ.

   Note that (2) can't guarantee this alone: Two ModuleName imports in
   separate units can (and likely do) map to the same `Module`.

Note that the previous implementation failed to achieve the
no-duplicate-work summarisation invariant, and we ended up doing a
quadratic amount of processing in scenarios like test
`MultiComponentModules100`.

See also Note [Downsweep Control Flow and Caching]

Fixes #27461

Perf changes:
         MultiComponentModules(normal) ghc/alloc  2,097,389,264  1,992,186,736  -5.0% GOOD
      MultiComponentModules100(normal) ghc/alloc 24,310,173,770 21,293,867,360 -12.4% GOOD
   MultiComponentModulesRecomp(normal) ghc/alloc    602,761,394    498,543,984 -17.3% GOOD
MultiComponentModulesRecomp100(normal) ghc/alloc 11,885,968,240  8,895,404,864 -25.2% GOOD

-------------------------
Metric Decrease:
    MultiComponentModules
    MultiComponentModules100
    MultiComponentModulesRecomp
    MultiComponentModulesRecomp100
-------------------------

ebc4047b

by Rodrigo Mesquita at 2026-08-15T06:29:53-04:00

implicitRequirementsShallow can never reach HoleUnit

findImportedModule will never return `HoleUnit` for a `ModuleName`
(a `HoleUnit` can only be found as a signature instantiation, never as a
directly *imported* thing)

Therefore, we can drop `[ModuleName]` returned by
`implicitRequirementsShallow`, which makes many things dead code.
Namely, the call to `implicitRequirementsShallow` from
GHC.Driver.Downsweep which was a performance bottleneck (for doing lots
of duplicate work in findImportedModule) is now entirely gone.

Fixes #27053

In an MR with this patch and the downsweep refactor (previous commit), CI says:

         MultiComponentModules(normal) ghc/alloc  2,097,396,728  1,943,662,304  -7.3% GOOD
      MultiComponentModules100(normal) ghc/alloc 24,310,182,136 17,227,574,440 -29.1% GOOD
   MultiComponentModulesRecomp(normal) ghc/alloc    602,769,518    449,973,656 -25.3% GOOD
MultiComponentModulesRecomp100(normal) ghc/alloc 11,885,976,408  4,828,894,160 -59.4% GOOD

-------------------------
Metric Decrease:
    MultiComponentModules
    MultiComponentModules100
    MultiComponentModulesRecomp
    MultiComponentModulesRecomp100
-------------------------

85a6ab01

by Rodrigo Mesquita at 2026-08-15T06:29:53-04:00

downsweep: Cache negative results

When traversing a module graph structure, a uniquely identified node
should always expand to the same thing.

I don't see how visiting the same node which failed to be expanded a
first time would ever successfully expand the second time we try to
expand it (eg. when coming from a different edge to it -- it is still
the same node!). The node expansion is local, based just based on the
node itself, not on the path to get there.

Therefore, this patch removes the weird behavior and commentary of
`dfsBuild` wrt to `Nothing` not being cached and being potentially
expanded a second time around to something different, which was
misleading and, ultimately, incorrect.

Now, we have a `MGRes`, which is more explicit about a node being
Skipped just being a node that is ignored whenever it is found (and that
skip is cached) -- and we may want to do this due to failures or due to
just trying nodes which might not work on purpose, like hs-boots.

We uniformly cache positive and negative results and remove the
assumption that there might be an ordering in which the same node
visited at a later time might be expanded differently.

This makes it possible to traverse the module nodes in parallel without
a change in behavior, since there's no longer a hidden ordering
requirement.

56747c3f

by Rodrigo Mesquita at 2026-08-15T06:29:53-04:00

Organize and clean-up GHC.Driver.Downsweep

Simply some cosmetic changes, moving definitions around to structure the
module better into its relevant sections

(In go (ns ++ ss), it's not a problem to use ++ because it's a good
producer and we won't have to append fully before processing the next
item in go)

12f64118

by Wolfgang Jeltsch at 2026-08-15T06:31:12-04:00

Add support for textual output of bytecode file content

a737df91
by Brandon Chinn at 2026-08-15T12:40:25-04:00
```
Add law in qualified strings doc
```

e3188581

by Zubin Duggal at 2026-08-15T12:41:06-04:00

DmdAnal: Fix maxDmdType

We need to eta expand the smaller DmdType using defaultArgDmd, like in lubDmdType.

Introduce zipDmdType as a common combinator to implement both maxDmdType and lubDmdType
uniformly.

fixes #27626

ca9b0b22

by mangoiv at 2026-08-15T12:41:47-04:00

hadrian: set the executable bit for hie-bios.bat

1aac7095

by sheaf at 2026-08-16T04:37:16-04:00

Avoid wasteful allocations in mkTyConAppCo

The idiom "traverse isReflCo_maybe" followed by "map fst" used in
'GHC.Core.Coercion.mkTyConAppCo' was allocating a lot of waste.
This commit uses 'GHC.Data.Unboxed.traverseMaybeUB' to avoid all these
unnecessary intermediate allocations.

In a quick microbenchmark for 'mkTyConAppCo', this change resulted in:
  - refl case (all argument coercions are reflexive):
    - -60% runtime
    - -80% allocations
  - non-refl case:
    - from 0% to -12% runtime (depending on which argument is non-refl)
    - from 0% to -70% allocations ( -- '' -- )

Fixes #27648

-------------------------
Metric Decrease:
    FamAppCachePerf
    SimplCastPerf
    T12425
    T15703
    T26426
    T3064
    T9872a
    T9872b
    T9872b_defer
    T9872c
    T9872d
    T5321Fun
    T9020
    T9630
    TcPlugin_RewritePerf
Metric Increase:
    LinkableUsage02
-------------------------

3915e982

by Alan Zimmerman at 2026-08-16T04:37:58-04:00

EPA: Remove al_trailing from AnnList

It was not being used

fed942ac

by Andreas Klebinger at 2026-08-17T12:11:57-04:00

testsuite: Use sigkill in process009.

SIGHUB might have been blocked by a (grand)*parent of the test.
In such cases the test would fail as the python process would simply
exist gracefully instead of committing to a premature end.

By using SIGKILL we can rely on the signal not being blocked, fixing #27578
in the process.

574c875f
by Andreas Klebinger at 2026-08-17T12:12:39-04:00
```
Simplify comparison in DFM.hs

Fixes #27669
```

d8f1a2a3

by Alan Zimmerman at 2026-08-17T12:13:18-04:00

TTG: Add extension points to BooleanFormula

They are currently unused, but will be used for exact print
annotations next, allowing us to get rid of LocatedBF / SrcSpanAnnBF

9a82d258

by Alan Zimmerman at 2026-08-17T19:25:52+01:00

EPA: Remove LocatedBC / SrcSpanBF

The custom annotations are now in the BooleanFormula TTG extension
points, so LBooleanFormula can now use the standard LocatedA.

c58f6867