[Git][ghc/ghc][ghc-9.10] 19 commits: Remove unused ghc-internal module "GHC.Internal.Constants"

Andreas Klebinger (@AndreasK) gitlab at gitlab.haskell.org
Fri Dec 13 01:40:47 UTC 2024 


Andreas Klebinger pushed to branch ghc-9.10 at Glasgow Haskell Compiler / GHC


Commits:
8cb44392 by Matthew Craven at 2024-12-09T13:36:25+01:00
Remove unused ghc-internal module "GHC.Internal.Constants"

(cherry picked from commit c6c190718972330504c048b013e5c2596b3c0c1e)

- - - - -
c16c0dea by Matthew Craven at 2024-12-09T14:25:07+01:00
CorePrep: Rework lowering of BigNat# literals

Don't use bigNatFromWord#, because that's terrible:
 * We shouldn't have to traverse a linked list at run-time
   to build a BigNat# literal. That's just silly!
 * The static List object we have to create is much larger
   than the actual BigNat#'s contents, bloating code size.
 * We have to read the corresponding interface file,
   which causes un-tracked implicit dependencies. (#23942)

Instead, encode them into the appropriate platform-dependent
sequence of bytes, and generate code that copies these bytes
at run-time from an Addr# literal into a new ByteArray#.
A ByteArray# literal would be the correct thing to generate,
but these are not yet supported; see also #17747.

Somewhat surprisingly, this change results in a slight
reduction in compiler allocations, averaging around 0.5%
on ghc's compiler performance tests, including when compiling
programs that contain no bignum literals to begin with.
The specific cause of this has not been investigated.

Since this lowering no longer reads the interface file for
GHC.Num.BigNat, the reasoning in Note [Depend on GHC.Num.Integer]
is obsoleted.  But the story of un-tracked built-in dependencies
remains complex, and Note [Tracking dependencies on primitives]
now exists to explain this complexity.

Additionally, many empty imports have been modified to refer to
this new note and comply with its guidance.  Several empty imports
necessary for other reasons have also been given brief explanations.

Metric Decrease:
    MultiLayerModulesTH_OneShot

(cherry picked from commit 6d8f274b8677fcf9519d569875145f9f5434d779)

- - - - -
0b3c9d24 by Andreas Klebinger at 2024-12-09T14:27:39+01:00
Add changelog entry for BigNat# lowering changes.

- - - - -
53d78e35 by Fendor at 2024-12-09T17:11:34+01:00
Replace `SizedSeq` with `FlatBag` for flattened structure

LinkedLists are notoriously memory ineffiecient when all we do is
traversing a structure.
As 'UnlinkedBCO' has been identified as a data structure that impacts
the overall memory usage of GHCi sessions, we avoid linked lists and
prefer flattened structure for storing.

We introduce a new memory efficient representation of sequential
elements that has special support for the cases:

* Empty
* Singleton
* Tuple Elements

This improves sharing in the 'Empty' case and avoids the overhead of
'Array' until its constant overhead is justified.

(cherry picked from commit 5f085d3af61e3f7a73652dfc1ae57e7ed7d691f2)

- - - - -
d4cf1dc7 by Fendor at 2024-12-09T17:11:34+01:00
Compact FlatBag array representation

`Array` contains three additional `Word`'s we do not need in `FlatBag`. Move
`FlatBag` to `SmallArray`.

Expand the API of SmallArray by `sizeofSmallArray` and add common
traversal functions, such as `mapSmallArray` and `foldMapSmallArray`.
Additionally, allow users to force the elements of a `SmallArray`
via `rnfSmallArray`.

(cherry picked from commit 82cfe10c8c3ec68e1b054e2d6b88e1a8830c60bf)

- - - - -
a90fac71 by Fendor at 2024-12-09T17:11:34+01:00
Avoid UArray when indexing is not required

`UnlinkedBCO`'s can occur many times in the heap. Each `UnlinkedBCO`
references two `UArray`'s but never indexes them. They are only needed
to encode the elements into a `ByteArray#`. The three words for
the lower bound, upper bound and number of elements are essentially
unused, thus we replace `UArray` with a wrapper around `ByteArray#`.
This saves us up to three words for each `UnlinkedBCO`.

Further, to avoid re-allocating these words for `ResolvedBCO`, we repeat
the procedure for `ResolvedBCO` and add custom `Binary` and `Show` instances.

For example, agda's repl session has around 360_000 UnlinkedBCO's,
so avoiding these three words is already saving us around 8MB residency.

(cherry picked from commit 88cb3e1079e88ba10065ce260a96095ae96d58e8)

- - - - -
68a1c9dd by Andreas Klebinger at 2024-12-09T17:11:34+01:00
Changelog for !12170 and !12142

- - - - -
73f25e46 by Rodrigo Mesquita at 2024-12-09T17:11:34+01:00
rts: free error message before returning

Fixes a memory leak in rts/linker/PEi386.c

(cherry picked from commit dd530bb7e22e953e4cec64a5fd6c39fddc152c6f)

- - - - -
c9979fed by Alexis King at 2024-12-09T17:11:34+01:00
linker: Avoid linear search when looking up Haskell symbols via dlsym

See the primary Note [Looking up symbols in the relevant objects] for a
more in-depth explanation.

When dynamically loading a Haskell symbol (typical when running a splice or
GHCi expression), before this commit we would search for the symbol in
all dynamic libraries that were loaded. However, this could be very
inefficient when too many packages are loaded (which can happen if there are
many package dependencies) because the time to lookup the would be
linear in the number of packages loaded.

This commit drastically improves symbol loading performance by
introducing a mapping from units to the handles of corresponding loaded
dlls. These handles are returned by dlopen when we load a dll, and can
then be used to look up in a specific dynamic library.

Looking up a given Name is now much more precise because we can get
lookup its unit in the mapping and lookup the symbol solely in the
handles of the dynamic libraries loaded for that unit.

In one measurement, the wait time before the expression was executed
went from +-38 seconds down to +-2s.

This commit also includes Note [Symbols may not be found in pkgs_loaded],
explaining the fallback to the old behaviour in case no dll can be found
in the unit mapping for a given Name.

Fixes #23415

Co-authored-by: Rodrigo Mesquita (@alt-romes)
(cherry picked from commit e008a19a7f9e8f22aada0b4e1049744f49d39aad)

- - - - -
b663c9e0 by Rodrigo Mesquita at 2024-12-09T17:11:34+01:00
rts: Make addDLL a wrapper around loadNativeObj

Rewrite the implementation of `addDLL` as a wrapper around the more
principled `loadNativeObj` rts linker function. The latter should be
preferred while the former is preserved for backwards compatibility.

`loadNativeObj` was previously only available on ELF platforms, so this
commit further refactors the rts linker to transform loadNativeObj_ELF
into loadNativeObj_POSIX, which is available in ELF and MachO platforms.

The refactor made it possible to remove the `dl_mutex` mutex in favour
of always using `linker_mutex` (rather than a combination of both).

Lastly, we implement `loadNativeObj` for Windows too.

(cherry picked from commit dcfaa190e1e1182a2efe4e2f601affbb832a49bb)

- - - - -
67890fdb by Rodrigo Mesquita at 2024-12-09T17:11:34+01:00
Use symbol cache in internal interpreter too

This commit makes the symbol cache that was used by the external
interpreter available for the internal interpreter too.

This follows from the analysis in #23415 that suggests the internal
interpreter could benefit from this cache too, and that there is no good
reason not to have the cache for it too. It also makes it a bit more
uniform to have the symbol cache range over both the internal and
external interpreter.

This commit also refactors the cache into a function which is used by
both `lookupSymbol` and also by `lookupSymbolInDLL`, extending the
caching logic to `lookupSymbolInDLL` too.

(cherry picked from commit 12931698261a1cee6a00b731d143270cd60e5f2d)

- - - - -
353b6ec1 by Ben Gamari at 2024-12-09T17:11:34+01:00
testsuite: Add test for lookupSymbolInNativeObj

(cherry picked from commit dccd3ea159b03cc1972cf47ee3cf8bda73ec0c5a)

- - - - -
920ccafc by Andreas Klebinger at 2024-12-09T17:11:34+01:00
Changelog for !12264 (Lookup symbols in relevant DLLs only)

- - - - -
99399b92 by Andreas Klebinger at 2024-12-09T17:12:58+01:00
NCG: Fix a bug where we errounously removed a required jump instruction.

Add a new method to the Instruction class to check if we can eliminate a
jump in favour of fallthrough control flow.

Fixes #24507

(cherry picked from commit 0fe2b410ac0d8951f07ffcc9f3c6c97bc312df48)

- - - - -
6ea0d4f7 by Andreas Klebinger at 2024-12-09T17:13:42+01:00
Add changelog for !12370 - Bug in jump shortcutting.

- - - - -
8692ced5 by Simon Peyton Jones at 2024-12-09T17:18:17+01:00
Don't generate wrappers for `type data` constructors with StrictData

Previously, the logic for checking if a data constructor needs a wrapper or not
would take into account whether the constructor's fields have explicit
strictness (e.g., `data T = MkT !Int`), but the logic would _not_ take into
account whether `StrictData` was enabled. This meant that something like `type
data T = MkT Int` would incorrectly generate a wrapper for `MkT` if
`StrictData` was enabled, leading to the horrible errors seen in #24620. To fix
this, we disable generating wrappers for `type data` constructors altogether.

Fixes #24620.

Co-authored-by: Ryan Scott <ryan.gl.scott at gmail.com>
(cherry picked from commit 5e4f4ba835fd24135759ee7a2d0d5c636a8a1505)

- - - - -
c52e8047 by Andreas Klebinger at 2024-12-09T17:19:50+01:00
Changelog for !12416

Entry for "Don't generate wrappers for `type data` constructors with StrictData."

- - - - -
8e13b22e by Matthew Pickering at 2024-12-09T17:21:24+01:00
Linearise ghc-internal and base build

This is achieved by requesting the final package database for
ghc-internal, which mandates it is fully built as a dependency of
configuring the `base` package. This is at the expense of cross-package
parrallelism between ghc-internal and the base package.

Fixes #24436

(cherry picked from commit 8a06ddf68bb5a9985e3a7b8464dd04b928c36b90)

- - - - -
220f15b2 by Andreas Klebinger at 2024-12-12T15:19:22+01:00
Accept backport metric changes.

The MLM test regresses slightly (+2.5% compiler bytes allocated).
That seems within reason.

-------------------------
Metric Increase:
    MultiLayerModulesTH_OneShot
-------------------------

- - - - -


30 changed files:

- compiler/GHC.hs
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/PrimOps.hs-boot
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/ByteCode/Linker.hs
- compiler/GHC/ByteCode/Types.hs
- compiler/GHC/Cmm/Dominators.hs
- compiler/GHC/CmmToAsm/AArch64.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/BlockLayout.hs
- compiler/GHC/CmmToAsm/Instr.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/PPC.hs
- compiler/GHC/CmmToAsm/PPC/Instr.hs
- compiler/GHC/CmmToAsm/Reg/Liveness.hs
- compiler/GHC/CmmToAsm/X86.hs
- compiler/GHC/CmmToAsm/X86/Instr.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/CoreToStg/Prep.hs
- + compiler/GHC/Data/FlatBag.hs
- compiler/GHC/Data/SmallArray.hs
- compiler/GHC/Data/Word64Map/Strict.hs
- compiler/GHC/Driver/CmdLine.hs
- compiler/GHC/Driver/Config/CoreToStg/Prep.hs
- compiler/GHC/Driver/Config/Diagnostic.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Plugins.hs
- compiler/GHC/Iface/Errors/Ppr.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8958612c274531bfe8fd3a033061586610f2c574...220f15b278acb09433b529cf91c10fc756f6e67e

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8958612c274531bfe8fd3a033061586610f2c574...220f15b278acb09433b529cf91c10fc756f6e67e
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/20241212/7526482c/attachment-0001.html>

More information about the ghc-commits mailing list