- ghc-commits - Haskell.org

[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 9 commits: hadrian: remove redundant library/rts ways definitions from stock flavours
by Marge Bot (＠marge-bot) 12 Mar '26

12 Mar '26

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: dfc2b01b by Cheng Shao at 2026-03-11T20:57:19+01:00 hadrian: remove redundant library/rts ways definitions from stock flavours This patch removes redundant library/rts ways definitions from stock flavours in hadrian; they can be replaced by applying appropriate filters on `defaultFlavour`. - - - - - 5811b146 by Teo Camarasu at 2026-03-12T10:50:52-04:00 ghc-internal: move bits Weak of finalizer interface to base We move parts of the Weak finalizer interface to `base` only the parts that the RTS needs to know about are kept in `ghc-internal`. This lets us then prune our imports somewhat and get rid of some SOURCE imports. Resolves #26985 - - - - - 6adfde46 by Simon Jakobi at 2026-03-12T10:50:52-04:00 Add regression test for #2057 Test that GHC stops after an interface-file error instead of continuing into the linker. The test constructs a stale package dependency on purpose. `pkgB` is compiled against one version of package `A`, then the same unit id is replaced by an incompatible build of `A`. When `Main` imports `B`, GHC has to read `B.hi`, finds an unfolding that still mentions the old `A`, and should fail while loading interfaces. Closes #2057. Assisted-by: Codex - - - - - 98689f07 by Sylvain Henry at 2026-03-12T10:51:25-04:00 JS: fix recompilation avoidance (#23013) - we were checking the mtime of the *.jsexe directory, not of a file - we were not computing the PkgsLoaded at all - - - - - c679ab3c by Cheng Shao at 2026-03-12T10:51:26-04:00 hadrian: bump index state & bootstrap plans This patch bumps hadrian index state & bootstrap plans: - The updated index state allows bootstrapping from 9.14 without cabal allow-newer hacks - The updated bootstrap plans all contain shake-0.19.9 containing important bugfix, allowing a subsequent patch to bump shake bound to ensure the bugfix is included - ghc 9.14.1 bootstrap plan is added - - - - - bc6f542a by Cheng Shao at 2026-03-12T10:51:26-04:00 ci: add ghc 9.14.1 to bootstrap matrix This patch adds ghc 9.14.1 to bootstrap matrix, so that we test bootstrapping from ghc 9.14.1. - - - - - 46f10988 by Sylvain Henry at 2026-03-12T10:51:32-04:00 T17912: wait for opener thread to block before killing it (#24739) Instead of a fixed 1000ms delay, poll threadStatus until the opener thread is in BlockedOnForeignCall, ensuring killThread only fires once the thread is provably inside the blocking open() syscall. This prevents the test from accidentally passing on Windows due to scheduling races. - - - - - 6cc98c5d by Cheng Shao at 2026-03-12T10:51:32-04:00 template-haskell: fix redundant import in Language.Haskell.TH.Quote This patch fixes a redundant import in `Language.Haskell.TH.Quote` that causes a ghc build failure when bootstrapping from 9.14 with validate flavours. Fixes #27014. - - - - - c37fcd8f by Brandon Simmons at 2026-03-12T10:51:39-04:00 Add a cumulative gc_sync_elapsed_ns counter to GHC.Internal.Stats This makes it possible to get an accurate view of time spent in sync phase when using prometheus-style sampling. Previously this was only available for the most recent GC. This intentionally leaves GHC.Stats API unchanged since it is marked as deprecated, and API changes there require CLC approval. Fixes #26944 - - - - - 66 changed files: - .gitlab-ci.yml - .gitlab/ci.sh - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Linker/Loader.hs - hadrian/bootstrap/generate_bootstrap_plans - hadrian/bootstrap/plan-9_10_1.json - hadrian/bootstrap/plan-9_10_2.json - hadrian/bootstrap/plan-9_10_3.json - hadrian/bootstrap/plan-9_12_1.json - hadrian/bootstrap/plan-9_12_2.json - + hadrian/bootstrap/plan-9_14_1.json - hadrian/bootstrap/plan-bootstrap-9_10_1.json - hadrian/bootstrap/plan-bootstrap-9_10_2.json - hadrian/bootstrap/plan-bootstrap-9_10_3.json - hadrian/bootstrap/plan-bootstrap-9_12_1.json - hadrian/bootstrap/plan-bootstrap-9_12_2.json - + hadrian/bootstrap/plan-bootstrap-9_14_1.json - hadrian/cabal.project - hadrian/src/Settings/Flavours/Development.hs - hadrian/src/Settings/Flavours/GhcInGhci.hs - hadrian/src/Settings/Flavours/Quick.hs - hadrian/src/Settings/Flavours/QuickCross.hs - hadrian/src/Settings/Flavours/Quickest.hs - libraries/base/src/GHC/Stats.hs - libraries/base/src/GHC/Weak.hs - libraries/base/src/GHC/Weak/Finalize.hs - − libraries/base/src/GHC/Weak/Finalizehs - libraries/base/src/System/Mem/Weak.hs - libraries/base/tests/IO/T17912.hs - libraries/base/tests/IO/all.T - libraries/ghc-internal/CHANGELOG.md - − libraries/ghc-internal/src/GHC/Internal/Conc/Sync.hs-boot - − libraries/ghc-internal/src/GHC/Internal/IO/Handle/Text.hs-boot - libraries/ghc-internal/src/GHC/Internal/Stats.hsc - libraries/ghc-internal/src/GHC/Internal/TopHandler.hs - libraries/ghc-internal/src/GHC/Internal/Weak.hs - libraries/ghc-internal/src/GHC/Internal/Weak/Finalize.hs - libraries/template-haskell/Language/Haskell/TH/Quote.hs - rts/Stats.c - rts/include/RtsAPI.h - testsuite/.gitignore - testsuite/tests/annotations/should_run/all.T - − testsuite/tests/driver/OneShotTH.stdout-javascript-unknown-ghcjs - + testsuite/tests/driver/T2057/Makefile - + testsuite/tests/driver/T2057/README.md - + testsuite/tests/driver/T2057/T2057.stderr - + testsuite/tests/driver/T2057/all.T - + testsuite/tests/driver/T2057/app/Main.hs - + testsuite/tests/driver/T2057/pkgA1/A.hs - + testsuite/tests/driver/T2057/pkgA1/pkg.conf - + testsuite/tests/driver/T2057/pkgA2/A.hs - + testsuite/tests/driver/T2057/pkgA2/pkg.conf - + testsuite/tests/driver/T2057/pkgB/B.hs - + testsuite/tests/driver/T2057/pkgB/pkg.conf - + testsuite/tests/driver/T20604/T20604.stdout-javascript-unknown-ghcjs - testsuite/tests/driver/T20604/all.T - testsuite/tests/driver/all.T - testsuite/tests/driver/fat-iface/fat010.stdout-javascript-unknown-ghcjs - testsuite/tests/driver/recomp011/all.T - testsuite/tests/driver/recompHash/recompHash.stdout-javascript-unknown-ghcjs - testsuite/tests/driver/recompNoTH/recompNoTH.stdout-javascript-unknown-ghcjs - − testsuite/tests/driver/th-new-test/th-new-test.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/ghc-experimental-exports.stdout - testsuite/tests/interface-stability/ghc-experimental-exports.stdout-mingw32 The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6af6ba920c0d9786bfde6639ab6274… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6af6ba920c0d9786bfde6639ab6274… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/manngoiv/release-trackign] release tracking: add a release tracking ticket
by Magnus (＠MangoIV) 12 Mar '26

12 Mar '26

Magnus pushed to branch wip/manngoiv/release-trackign at Glasgow Haskell Compiler / GHC Commits: d4cdfcbf by mangoiv at 2026-03-12T14:17:25+01:00 release tracking: add a release tracking ticket Adds a new template for release tracking ala #16816. The information has been brought up to date with https://gitlab.haskell.org/ghc/ghc-hq/-/blob/main/release-management.mkd Resolves #26691 - - - - - 1 changed file: - + .gitlab/issue_templates/release_tracking.md Changes: ===================================== .gitlab/issue_templates/release_tracking.md ===================================== @@ -0,0 +1,203 @@ + + +This is the release checklist for the **TODO milestone**. + + + +See the milestone for the planned release schedule, and other details. See [GHC HQ - Release Management](https://gitlab.haskell.org/ghc/ghc-hq/-/blob/main/release-manag… for release policies. + +This template is part of the ghc repository at `.gitlab/issue_templates/release_tracking.md`. + + +# Pre-fork checklist + + +When forking a new release branch for a new major release series (e.g. `ghc-9.14`), please check the following: + +* [ ] Add the release to the [status page](https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-Status), including a link to the milestone. +* [ ] Verify that the platform support documentation is up-to-date with reality: + * https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms/windows + * https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms/ +* [ ] Remove the release notes for the previous release (e.g. `docs/users_guide/8.6.*-notes.rst`) +* [ ] In `configure.ac` update `MinBootGhcVersion` to be the major version of the last supported bootstrap compiler. We currently guarantee bootstrapping with the last two major releases; therefore, when preparing, e.g., GHC `9.14` you should set `MinBootGhcVersion` to `9.10`. +* [ ] Create the new branch: `git branch ghc-9.14` +* [ ] In the new branch bump the version number in `configure.ac` to, e.g., `9.14` +* [ ] In `master` bump the version number in `configure.ac` to that of the next development series, e.g., `9.15` and ensure that `MinBootGhcVersion` is set correctly +* [ ] Verify that package versions have been bumped as necessary under PVP: + * [ ] `base` + * [ ] `template-haskell` + * [ ] `ghc-prim` +* [ ] Tag this `master` commit as, e.g., `ghc-9.14-start` +* [ ] Push all of the above tags and branches +* [ ] Create a new worksheet in the GHC submodule tracking spreadsheet (ask in `#ghc` for a link), populate the "current" and "desired" version columns, and send an email to submodule maintainers and `ghc-releases(a)haskell.org` asking them to notify us of their needs +* [ ] After forking, remove release notes from `master` and start a new set of release notes for the next release +* [ ] After forking, notify `ghc-releases(a)haskell.org` that fork has been made +* [ ] Create a weekly scheduled pipeline building the new branch to ensure that it does not bit-rot and bindists are persistently available + +# Pre-release checklist + +* [ ] Ensure that the Haddock (haddock-library, haddock-api) version numbers have been appropriately bumped. +* [ ] Ensure that submodules are on released tags (the below is produced using [this script](https://gitlab.haskell.org/bgamari/ghc-utils/blob/master/rel-eng/su…) + * [ ] `libraries/Cabal`: version *todo* + * [ ] `libraries/Win32`: version *todo* + * [ ] `libraries/array`: version *todo* + * [ ] `libraries/binary`: version *todo* + * [ ] `libraries/bytestring`: version *todo* + * [ ] `libraries/containers`: version *todo* + * [ ] `libraries/deepseq`: version *todo* + * [ ] `libraries/directory`: version *todo* + * [ ] `libraries/exceptions`: version *todo* + * [ ] `libraries/file-io`: version *todo* + * [ ] `libraries/filepath`: version *todo* + * [ ] `libraries/haskeline`: version *todo* + * [ ] `libraries/hpc`: version *todo* + * [ ] `libraries/libffi-clib`: version *todo* + * [ ] `libraries/mtl`: version *todo* + * [ ] `libraries/os-string`: version *todo* + * [ ] `libraries/parsec`: version *todo* + * [ ] `libraries/pretty`: version *todo* + * [ ] `libraries/process`: version *todo* + * [ ] `libraries/semaphore-compat`: version *todo* + * [ ] `libraries/stm`: version *todo* + * [ ] `libraries/template-haskell-lift`: version *todo* + * [ ] `libraries/template-haskell-quasiquoter`: version *todo* + * [ ] `libraries/terminfo`: version *todo* + * [ ] `libraries/text`: version *todo* + * [ ] `libraries/time`: version *todo* + * [ ] `libraries/transformers`: version *todo* + * [ ] `libraries/unix`: version *todo* + * [ ] `libraries/xhtml`: version *todo* + * [ ] `utils/hpc`: version *todo* + * [ ] `utils/hsc2hs`: version *todo* +* [ ] Announce the boot lib versions that are planned to be included in the next release on the + [Boot libraries maintainers mailing list](mailto:ghc-boot-libraries@haskell.org), then allow for appropriate amount of grace time + for boot library maintainers to include revisions. +* [ ] Ensure that all of the versions above are newer than the ones for older major releases and incorporate any patch updates +* [ ] Notify stakeholders of release progress, **including timeline, reason, what to look out for, platform tier changes, build platform changes, Bindist Changes** [^1]: + * [ ] [Julian Ospald](mailto:hasufell@posteo.de) + * [ ] [GHC releases](mailto:ghc-releases@haskell.org) + * [ ] [GHC developers](mailto:ghc-devs@haskell.org) + * [ ] [GHC users](mailto:glasgow-haskell-users@haskell.org) +* [ ] Non-released submodules up-to-date: + * [ ] `nofib` (upstream: ghc/nofib>) + * [ ] `libffi-tarballs` (upstream: ghc/libffi-tarballs>) + * [ ] `libraries/ghc-bignum/gmp/gmp-tarballs` (upstream: ghc/gmp-tarballs>) +* [ ] `LlvmMinVersion` and `LlvmMaxVersion` in `configure.ac` is targetting intended LLVM version +* [ ] `llvm-targets` file [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-… +* [ ] Release notes (`docs/users_guide/x.y.z-notes.rst`) written + * Release notes linked in `docs/users_guide/release-notes.rst` + * LLVM version requirement mentioned +* [ ] Remove "Included libraries" sections from old release notes +* [ ] `autoconf` scripts [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-… +* [ ] Check that Unicode database in `base` (`libraries/base/cbits/README.Unicode`) reflects current standard release (http://www.unicode.org/versions/latest/) +* [ ] Verify that the ~"backport needed" label has no more issues/merge requests needing backport +* [ ] Verify that all CI builds are green before moving to *release checklist* +* [ ] Update hadrian bootstrap plans for the latest compiler releases: + * Update `hadrian/bootstrap/generate_bootstrap_plans` to include any new compiler releases in the last two major release series + * Drop any plans that are outside of the bootstrap support window + * Run `hadrian/bootstrap/generate_bootstrap_plans` and commit the files that it generates + * Update `bootstrap_matrix` in `.gitlab-ci.yml` to reflect the most recent minor release in each major series supported by bootstrapping + +# Release candidate checklist + +* Announce on: + * [ ] [GHC developers](mailto:ghc-devs@haskell.org) + * [ ] [GHC releases](mailto:ghc-releases@haskell.org), + * [ ] [GHC users](mailto:glasgow-haskell-users@haskell.org) +* [ ] For minor releases: Ask stackage maintainers to test the release candidate. +* Give grace time + + +# Release checklist + +* [ ] Ensure that the [Migration](https://gitlab.haskell.org/ghc/ghc/wikis/migration/) page is up-to-date +* [ ] Push a provisional release commit to trigger the release builds using `git push -o ci.variable="RELEASE_JOB=yes"` +* [ ] Wait until builds finish; verify that they finished successfully +* [ ] Write down a link to the release pipeline here:  +* [ ] Fetch release artifacts: + ```bash + $ mkdir $VERSION + $ cd $VERSION + $ nix run $GHC/.gitlab/rel_eng#fetch-gitlab --pipeline $PIPELINE_ID --release $VERSION + ``` + where `GHC` is the path to a GHC source tree, `VERSION` is the version number, and `PIPELINE_ID` is the release pipeline id. +* [ ] Recompress release artifacts: `nix run $GHC/.gitlab/rel_eng#upload -- recompress` +* [ ] Generate hashes: `nix run $GHC/.gitlab/rel_eng#upload -- gen_hashes` +* [ ] Sign release artifacts: `nix run $GHC/.gitlab/rel_eng#upload -- sign` +* [ ] Upload to `downloads.haskell.org`: `nix run $GHC/.gitlab/rel_eng#upload -- upload` +* [ ] If most recent release: Update `latest` symlink: `nix run $GHC/.gitlab/rel_eng#upload -- set_symlink latest` +* [ ] Update `X.Y-latest` symlink: `nix run $GHC/.gitlab/rel_eng#upload -- set_symlink 9.8-latest` +* [ ] Purge CDN cache: `nix run $GHC/.gitlab/rel_eng#upload -- purge` +* [ ] Submit `ghcup` metadata upstream: + * Manually trigger the `ghcup-metadata-testing-release` job of the release pipeline + * Download the `metadata_test.yaml` artifact from the `ghcup-metadata-release` job of the release pipeline + * Clone [`ghcup-metadata`](https://github.com/haskell/ghcup-metadata/) + * Integrate the appropriate release section into `ghcup-metadata/ghcup-0.0.7.yaml` (or `ghcup-prerelease-0.0.7.yaml` for pre-releases) + * Replace the `&id<n>` identifiers with unique names + * Add the `Latest` (or `LatestPrerelease`) to the new release's `viTags` field + * Remove `Latest` for the previous release's `viTags` field; for pre-releases add the `Prerelease` tag) + * Add the `base-w.x.y.z` (e.g. `base-4.19.0.0`) tag to `viTags` + * Sign the resulting metadata YAML file with `gpg --detach-sign` + * Open a merge request submitting the metadata upstream + * Start a "Bindist installation" [workflow](https://github.com/haskell/ghcup-metadata/actions/workflows/bindi… +* [ ] [Make a release tag](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#tagging-the-r… +* [ ] Release/revise GHC-maintained libraries on Hackage using [this script](https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/rel_eng/up…: + * [ ] `libraries/base` + * [ ] `libraries/ghc-prim` + * [ ] `libraries/array` + * [ ] `libraries/stm` + * [ ] `libraries/ghc-heap` + * [ ] `libraries/ghc-compact` + * [ ] `libraries/ghc-boot` + * [ ] `libraries/ghc-boot-th` + * [ ] `libraries/hpc` + * [ ] `libraries/libiserv` + * [ ] `libraries/template-haskell` + * [ ] `libraries/ghc-bignum` +* [ ] Update ghc/homepage>: + * [ ] Write download page (see ghc/homepage>) + * [ ] Make sure that the Signing Key is correct for the relevant release + * [ ] Add news item to [`index.html`](https://gitlab.haskell.org/ghc/homepage/blob/master/index.shtml) + * [ ] Add link to [`download.shtml`](https://gitlab.haskell.org/ghc/homepage/blob/master/download.shtml). Be sure to link to the Migration guide. + * [ ] Look over changes locally + * [ ] Add release announcement to [GHC blog](https://gitlab.haskell.org/ghc/homepage/tree/master/blog). Be sure to link to the Migration guide. + * [ ] Push changes to `master` +* [ ] Announce on: + * [ ] [GHC developers](mailto:ghc-devs@haskell.org) + * [ ] [GHC releases](mailto:ghc-releases@haskell.org), + * [ ] [Boot libraries maintainers](mailto:ghc-boot-libraries@haskell.org) + * [ ] [GHC users](mailto:glasgow-haskell-users@haskell.org) + * [ ] adjacent matrix channels: #haskell-releases:matrix.org, #GHC:matrix.org, #ghc-devs:matrix.org + * [ ] [Haskell Cafe](mailto:haskell-cafe@haskell.org) + * [ ] Mention sponsors + * [ ] Mention ghc / ghc-hq + * [ ] Link to release notes and migration guide +* [ ] Announce on: [Haskell Discourse](https://discourse.haskell.org/), [/r/haskell](https://reddit.com/r/haskell), [/m/haskell](https://kbin.social/m/haskell) +* [ ] When releasing the latest version, update `latest` symlink on `downloads.haskell.org`, e.g. `ln -sfT 9.6.3 latest` if 9.6 was the latest major series. + +# Post-release checklist + +* [ ] Update the Wiki [status page](https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-Status) +* [ ] Update the [language pragma history](https://gitlab.haskell.org/ghc/ghc/wikis/language-pragma-history) +* [ ] Mark milestone as *closed* +* [ ] Update `/topic` in `#ghc` +* [ ] Update the [VersionHistory](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/librari… wiki page +* [ ] Set `RELEASE=NO` +* [ ] Create a release tracking ticket for the next release using the template in #16816 + +[^1]: Build platform changes are major changes to how GHC is being built from sources. + Bindist changes are significant changes to the toolchains, changes to the layout of the bindists or changes to the user facing installation procedure. + Platform tier changes are changes that move platforms up or down a tier or drop a given platform from the tierlist. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/d4cdfcbfc45c34219b53eae78a8544e… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/d4cdfcbfc45c34219b53eae78a8544e… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/manngoiv/release-trackign
by Magnus (＠MangoIV) 12 Mar '26

12 Mar '26

Magnus pushed new branch wip/manngoiv/release-trackign at Glasgow Haskell Compiler / GHC -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/tree/wip/manngoiv/release-trackign You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/26416] DmdAnal: Take stable unfoldings into account when determining argument demands
by Zubin (＠wz1000) 12 Mar '26

12 Mar '26

Zubin pushed to branch wip/26416 at Glasgow Haskell Compiler / GHC Commits: 870243e4 by Zubin Duggal at 2026-03-12T17:33:28+05:30 DmdAnal: Take stable unfoldings into account when determining argument demands Previously, demand analysis only looked at the RHS to compute argument demands. If the optimised RHS discarded uses of an argument that the stable unfolding still needed, it would be incorrectly marked absent. Worker/wrapper would then replace it with LitRubbish, and inlining the stable unfolding would use the rubbish value, causing a segfault. To fix, we introduce addUnfoldingDemands which analyses the stable unfolding with dmdAnal and combines its DmdType with the RHS's via the new `maxDmdType` which combines the demands of the stable unfolding with the rhs, so we can avoid any situation where we give an absent demand to something which is still used by the stable unfolding. Fixes #26416. - - - - - 8 changed files: - compiler/GHC/Core/Opt/DmdAnal.hs - compiler/GHC/Types/Demand.hs - testsuite/tests/dmdanal/should_compile/T18894.stderr - + testsuite/tests/dmdanal/should_run/M1.hs - + testsuite/tests/dmdanal/should_run/T26416.hs - + testsuite/tests/dmdanal/should_run/T26416.stdout - testsuite/tests/dmdanal/should_run/all.T - testsuite/tests/dmdanal/sigs/T21081.stderr Changes: ===================================== compiler/GHC/Core/Opt/DmdAnal.hs ===================================== @@ -23,7 +23,7 @@ import GHC.Core.DataCon import GHC.Core.Utils import GHC.Core.TyCon import GHC.Core.Type -import GHC.Core.FVs ( rulesRhsFreeIds, bndrRuleAndUnfoldingIds ) +import GHC.Core.FVs ( rulesRhsFreeIds, bndrRuleAndUnfoldingIds, idRuleVars ) import GHC.Core.Coercion ( Coercion ) import GHC.Core.TyCo.FVs ( coVarsOfCos ) import GHC.Core.TyCo.Compare ( eqType ) @@ -1106,9 +1106,22 @@ dmdAnalRhsSig top_lvl rec_flag env let_sd id rhs rhs_sd = mkCalledOnceDmds ww_arity adjusted_body_sd WithDmdType rhs_dmd_ty rhs' = dmdAnal env rhs_sd rhs - DmdType rhs_env rhs_dmds = rhs_dmd_ty - (final_rhs_dmds, final_rhs) = finaliseArgBoxities env id ww_arity - rhs_dmds (de_div rhs_env) rhs' + + -- See Note [Absence analysis for stable unfoldings and RULES], Wrinkle (W3) + full_dmd_ty = addUnfoldingDemands env rhs_sd id rhs_dmd_ty + DmdType full_rhs_env combined_rhs_dmds = full_dmd_ty + + final_rhs_dmds = finaliseArgBoxities env id ww_arity + combined_rhs_dmds (de_div full_rhs_env) rhs' + + -- Attach the final demands to the lambda binders of the RHS. + -- IMPORTANT: The lambda binders of final_rhs must carry the final demand + -- info, because worker/wrapper drives decisions from the idDemandInfo on + -- the lambdas (see mkWwstr_one), NOT from the strictness signature of the + -- function. So the demands must reflect both the unfolding combination + -- (from addUnfoldingDemands) and the boxity finalisation (from + -- finaliseArgBoxities). + final_rhs = setLamDmds final_rhs_dmds rhs' dmd_sig_arity = ww_arity + strictCallArity body_sd sig = mkDmdSigForArity dmd_sig_arity (DmdType sig_env final_rhs_dmds) @@ -1132,19 +1145,51 @@ dmdAnalRhsSig top_lvl rec_flag env let_sd id rhs -- we never get used-once info for FVs of recursive functions. -- See #14816 where we try to get rid of reuseEnv. rhs_env1 = case rec_flag of - Recursive -> reuseEnv rhs_env - NonRecursive -> rhs_env + Recursive -> reuseEnv full_rhs_env + NonRecursive -> full_rhs_env -- See Note [Absence analysis for stable unfoldings and RULES] - rhs_env2 = rhs_env1 `plusDmdEnv` demandRootSet env (bndrRuleAndUnfoldingIds id) + -- The unfolding FVs are already included in full_rhs_env via addUnfoldingDemands. + -- Here we only need demandRoots for RULES. + rhs_env2 = rhs_env1 `plusDmdEnv` demandRootSet env (filterVarSet isId (idRuleVars id)) -- See Note [Lazy and unleashable free variables] !(!sig_env, !weak_fvs) = splitWeakDmds rhs_env2 +setLamDmds :: [Demand] -> CoreExpr -> CoreExpr +-- Attach the demands to the outer lambdas of this expression +setLamDmds (dmd:dmds) (Lam v e) + | isTyVar v = Lam v (setLamDmds (dmd:dmds) e) + | otherwise = Lam (v `setIdDemandInfo` dmd) (setLamDmds dmds e) +setLamDmds dmds (Cast e co) = Cast (setLamDmds dmds e) co + -- This case happens for an OPAQUE function, which may look like + -- f = (\x y. blah) |> co + -- We give it strictness but no boxity (#22502) +setLamDmds _ e = e + -- In the OPAQUE case, the list of demands at this point might be + -- non-empty, e.g., when looking at a PAP. Hence don't panic (#22997). + splitWeakDmds :: DmdEnv -> (DmdEnv, WeakDmds) splitWeakDmds (DE fvs div) = (DE sig_fvs div, weak_fvs) where (!weak_fvs, !sig_fvs) = partitionVarEnv isWeakDmd fvs +-- | If there is a stable unfolding, combine argument demands and free variable +-- demands from the unfolding with those from the RHS. +-- See Note [Absence analysis for stable unfoldings and RULES], Wrinkle (W3). +-- See Note [Combining demands for stable unfoldings] in GHC.Types.Demand. +addUnfoldingDemands :: AnalEnv -> SubDemand -> Id -> DmdType -> DmdType +addUnfoldingDemands env rhs_sd id rhs_dmd_ty + | isStableUnfolding unf + , Just unf_body <- maybeUnfoldingTemplate unf + , let WithDmdType unf_dmd_ty _ = dmdAnal env rhs_sd unf_body + = -- pprTrace "addUnfoldingDemands" (ppr id $$ ppr rhs_dmd_ty $$ ppr unf_dmd_ty) $ + maxDmdType rhs_dmd_ty unf_dmd_ty + + | otherwise + = rhs_dmd_ty -- No stable unfolding, nothing to do + where + unf = realIdUnfolding id + -- | The result type after applying 'idArity' many arguments. Returns 'Nothing' -- when the type doesn't have exactly 'idArity' many arrows. resultType_maybe :: Id -> Maybe Type @@ -1482,10 +1527,21 @@ and transform to Now if f is subsequently inlined, we'll use 'g' and ... disaster. -SOLUTION: if f has a stable unfolding, treat every free variable as a -/demand root/, that is: Analyse it as if it was a variable occurring in a +SOLUTION for stable unfoldings: in `dmdAnalRhsSig`, if the function has a +stable unfolding, analyse it with `dmdAnal` and combine the resulting `DmdType` +with the RHS's `DmdType`. This is done by `addUnfoldingDemands`, which uses +`maxDmdType` to combine both argument demands and free variable demands. +See Note [Combining demands for stable unfoldings] in GHC.Types.Demand for +details of the combining operation. + +This handles both the free variables and arguments of stable unfoldings in one +go. For example, in the scenario above, the unfolding's `DmdType` will mention +`g` as a free variable, so `maxDmdType` will keep it alive. + +SOLUTION for RULES: treat every Id free in the RHS of a RULE as a +/demand root/, that is: analyse it as if it was a variable occurring in a 'topDmd' context. This is done in `demandRoot` (which we also use for exported -top-level ids). Do the same for Ids free in the RHS of any RULES for f. +top-level ids). Wrinkles: @@ -1502,7 +1558,7 @@ Wrinkles: this, that actually happened in practice. (W2) You might wonder why we don't simply take the free vars of the - unfolding/RULE and map them to topDmd. The reason is that any of the free vars + RULE and map them to topDmd. The reason is that any of the free vars might have demand signatures themselves that in turn demand transitive free variables and that we hence need to unleash! This came up in #23208. Consider @@ -1524,6 +1580,24 @@ Wrinkles: for `sg`, failing to unleash the signature and hence observed an absent error instead of the `really important message`. + (W3) The stable unfolding solution above handles /free variables/, but + what about /arguments/? Consider (#26416) + + fromVector :: (Storable a, KnownNat n) => Vector a -> Vector a + fromVector v = ... (uses Storable dictionary) ... + {-# INLINABLE fromVector #-} + + Suppose that the optimised RHS of `fromVector` somehow discards the use of + the Storable dictionary, but the stable unfolding still uses it. Then the + demand signature will say that the Storable dictionary argument is absent, + and worker/wrapper will replace it with `LitRubbish`. But when the + worker's unfolding is inlined, it will use that rubbish value as a real + dictionary, leading to a segfault! + + `addUnfoldingDemands` handles this too: since `maxDmdType` combines both + the argument demands and free variable demands from the unfolding's + `DmdType` with the RHS's, argument absence is correctly prevented. + Note [DmdAnal for DataCon wrappers] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We give DataCon wrappers a (necessarily flat) demand signature in @@ -2001,22 +2075,20 @@ positiveTopBudget (MkB n _) = n >= 0 finaliseArgBoxities :: AnalEnv -> Id -> Arity -> [Demand] -> Divergence - -> CoreExpr -> ([Demand], CoreExpr) + -> CoreExpr -> [Demand] -- POSTCONDITION: --- If: (dmds', rhs') = finaliseArgBoxitities ... dmds .. rhs +-- If: dmds' = finaliseArgBoxities ... dmds .. rhs -- Then: -- dmds' is the same as dmds (including length), except for boxity info --- rhs' is the same as rhs, except for dmd info on lambda binders -- NB: For join points, length dmds might be greater than ww_arity +-- NB: rhs is needed only to count visible binders. finaliseArgBoxities env fn ww_arity arg_dmds div rhs -- Check for an OPAQUE function: see Note [OPAQUE pragma] -- In that case, trim off all boxity info from argument demands - -- and demand info on lambda binders -- See Note [The OPAQUE pragma and avoiding the reboxing of arguments] | isOpaquePragma (idInlinePragma fn) - , let trimmed_arg_dmds = map trimBoxity arg_dmds - = (trimmed_arg_dmds, set_lam_dmds trimmed_arg_dmds rhs) + = map trimBoxity arg_dmds -- Check that we have enough visible binders to match the -- ww arity; if not, we won't do worker/wrapper @@ -2027,7 +2099,7 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs -- It's a bit of a corner case. Anyway for now we pass on the -- unadulterated demands from the RHS, without any boxity trimming. | ww_arity > count isId bndrs - = (arg_dmds, rhs) + = arg_dmds -- The normal case | otherwise @@ -2036,10 +2108,7 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs -- , text "max" <+> ppr max_wkr_args -- , text "dmds before:" <+> ppr (map idDemandInfo (filter isId bndrs)) -- , text "dmds after: " <+> ppr arg_dmds' ]) $ - (arg_dmds', set_lam_dmds arg_dmds' rhs) - -- set_lam_dmds: we must attach the final boxities to the lambda-binders - -- of the function, both because that's kosher, and because CPR analysis - -- uses the info on the binders directly. + arg_dmds' where opts = ae_opts env (bndrs, _body) = collectBinders rhs @@ -2047,8 +2116,11 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs arg_triples :: [(Type, StrictnessMark, Demand)] arg_triples = take ww_arity $ - [ (idType bndr, NotMarkedStrict, get_dmd bndr) - | bndr <- bndrs, isRuntimeVar bndr ] + zipWith mk_triple + [ bndr | bndr <- bndrs, isRuntimeVar bndr ] + arg_dmds + where + mk_triple bndr arg_dmd = (idType bndr, NotMarkedStrict, get_dmd arg_dmd) arg_dmds' = ww_arg_dmds ++ map trimBoxity (drop ww_arity arg_dmds) -- If ww_arity < length arg_dmds, the leftover ones @@ -2064,12 +2136,10 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs -- This is the budget initialisation step of -- Note [Worker argument budget] - get_dmd :: Id -> Demand - get_dmd bndr + get_dmd :: Demand -> Demand + get_dmd dmd | is_bot_fn = unboxDeeplyDmd dmd -- See Note [Boxity for bottoming functions], | otherwise = dmd -- case (B) - where - dmd = idDemandInfo bndr -- is_bot_fn: see Note [Boxity for bottoming functions] is_bot_fn = div == botDiv @@ -2126,19 +2196,6 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs | positiveTopBudget bg_inner' = (bg_inner', dmd') | otherwise = (bg_inner, trimBoxity dmd) - set_lam_dmds :: [Demand] -> CoreExpr -> CoreExpr - -- Attach the demands to the outer lambdas of this expression - set_lam_dmds (dmd:dmds) (Lam v e) - | isTyVar v = Lam v (set_lam_dmds (dmd:dmds) e) - | otherwise = Lam (v `setIdDemandInfo` dmd) (set_lam_dmds dmds e) - set_lam_dmds dmds (Cast e co) = Cast (set_lam_dmds dmds e) co - -- This case happens for an OPAQUE function, which may look like - -- f = (\x y. blah) |> co - -- We give it strictness but no boxity (#22502) - set_lam_dmds _ e = e - -- In the OPAQUE case, the list of demands at this point might be - -- non-empty, e.g., when looking at a PAP. Hence don't panic (#22997). - finaliseLetBoxity :: AnalEnv -> Type -- ^ Type of the let-bound Id ===================================== compiler/GHC/Types/Demand.hs ===================================== @@ -23,6 +23,8 @@ module GHC.Types.Demand ( lubCard, lubDmd, lubSubDmd, -- *** Greatest lower bound glbCard, + -- *** Maximum (glb on strictness, lub on usage) + maxCard, maxDmd, -- *** Plus plusCard, plusDmd, plusSubDmd, -- *** Multiply @@ -49,13 +51,13 @@ module GHC.Types.Demand ( -- * Demand environments DmdEnv(..), addVarDmdEnv, mkTermDmdEnv, nopDmdEnv, plusDmdEnv, plusDmdEnvs, - multDmdEnv, reuseEnv, + lubDmdEnv, multDmdEnv, reuseEnv, -- * Demand types DmdType(..), dmdTypeDepth, -- ** Algebra nopDmdType, botDmdType, - lubDmdType, plusDmdType, multDmdType, discardArgDmds, + lubDmdType, maxDmdType, plusDmdType, multDmdType, discardArgDmds, -- ** Other operations peelFV, findIdDemand, addDemand, splitDmdTy, deferAfterPreciseException, @@ -864,6 +866,89 @@ lubSubDmd sd1@Poly{} sd2 = lubSubDmd sd2 sd1 -- Otherwise (Call `lub` Prod) return Top lubSubDmd _ _ = topSubDmd +{- Note [Combining demands for stable unfoldings] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +When a function has a stable unfolding, the optimised RHS and the unfolding +may have different demand signatures for the same arguments. This can happen +because: + + * The optimised RHS may have had transformations applied that reveal + strictness (e.g., inlining exposes a case on an argument). + Example: + RHS: x + Unfolding: head [x] + It's clear that the RHS is strict in `x`, but the demand analyser won't + spot that when it analyses the unfolding. + + * The optimised RHS may have had transformations applied that drop usage + (e.g., a rewrite rule fires that doesn't use an argument, or a seq on + a dictionary is dropped because dictionaries are known to terminate). + Example: + RHS: a + Unfolding: fst g + where `g` is in scope as `g = (a,b)`. + +See Note [Absence analysis for stable unfoldings and RULES] in +GHC.Core.Opt.DmdAnal for the broader context. + +When we inline the stable unfolding at a call site, we get the unfolding's +behaviour, not the RHS's. So we must be conservative and combine the demands: + + * For strictness (lower bounds): we can take the MAXIMUM (glb). + If the RHS reveals that an argument is strict, that strictness was + always there semantically - the analysis just couldn't see it in the + unfolding. Sound optimisations never make lazy code strict. + + * For usage (upper bounds): we must take the MAXIMUM (lub). + If the unfolding uses an argument but the RHS doesn't, we must not + mark it absent, or we'll replace it with rubbish that the unfolding + will then try to use, causing a segfault. See #26416. + +So for cardinality bounds [l1..u1] from RHS and [l2..u2] from unfolding, +we compute [max(l1,l2)..max(u1,u2)]. +-} + +-- | Takes the maximum of both the lower and upper bound of two 'Card's. +-- Semantically, this is glb on lower (strictness) and lub on upper (usage). +-- See Note [Combining demands for stable unfoldings]. +maxCard :: Card -> Card -> Card +-- Given Note [Bit vector representation for Card]: +-- * bit 0 (strictness): take AND (glb) - 0 means strict, so 0 wins +-- * bits 1,2 (usage): take OR (lub) - if either uses, result uses +maxCard (Card a) (Card b) = Card ((a .&. b .&. 0b001) .|. ((a .|. b) .&. 0b110)) + +-- | Takes the maximum of both the lower and upper bounds of two 'Demand's. +-- Semantically, glb on lower (strictness) and lub on upper (usage). +-- See Note [Combining demands for stable unfoldings]. +maxDmd :: Demand -> Demand -> Demand +maxDmd BotDmd dmd2 = dmd2 +maxDmd dmd1 BotDmd = dmd1 +maxDmd (n1 :* sd1) (n2 :* sd2) = + maxCard n1 n2 :* maxSubDmd sd1 sd2 + +maxSubDmd :: SubDemand -> SubDemand -> SubDemand +-- Shortcuts for neutral and absorbing elements. +maxSubDmd (Poly Unboxed C_00) sd = sd +maxSubDmd sd (Poly Unboxed C_00) = sd +maxSubDmd sd@(Poly Boxed C_1N) _ = sd +maxSubDmd _ sd@(Poly Boxed C_1N) = sd +-- Prod +maxSubDmd (Prod b1 ds1) (Poly b2 n2) + | let !d = polyFieldDmd b2 n2 + = mkProd (lubBoxity b1 b2) (strictMap (maxDmd d) ds1) +maxSubDmd (Prod b1 ds1) (Prod b2 ds2) + | equalLength ds1 ds2 + = mkProd (lubBoxity b1 b2) (strictZipWith maxDmd ds1 ds2) +-- Handle Call +maxSubDmd (Call n1 sd1) (viewCall -> Just (n2, sd2)) = + mkCall (maxCard n1 n2) (maxSubDmd sd1 sd2) +-- Handle Poly +maxSubDmd (Poly b1 n1) (Poly b2 n2) = Poly (lubBoxity b1 b2) (maxCard n1 n2) +-- Other Poly case by commutativity +maxSubDmd sd1@Poly{} sd2 = maxSubDmd sd2 sd1 +-- Otherwise (Call `max` Prod) return Top +maxSubDmd _ _ = topSubDmd + -- | Denotes '+' on 'Demand'. plusDmd :: Demand -> Demand -> Demand plusDmd AbsDmd dmd2 = dmd2 @@ -1834,6 +1919,26 @@ lubDmdType d1 d2 = DmdType lub_fv lub_ds lub_ds = zipWithEqual lubDmd ds1 ds2 lub_fv = lubDmdEnv fv1 fv2 +-- | Combine two 'DmdType's for stable unfolding analysis. +-- See Note [Combining demands for stable unfoldings]. +maxDmdType :: DmdType -> DmdType -> DmdType +maxDmdType (DmdType fv1 ds1) (DmdType fv2 ds2) + = DmdType combined_fv combined_ds + where + combined_fv = maxDmdEnv fv1 fv2 + combined_ds = go ds1 ds2 + -- If lists have different lengths, keep remaining ds1 (from RHS) + go rhs [] = rhs + go [] _ = [] + go (r:rhs) (u:unfs) = maxDmd r u : go rhs unfs + +-- | See Note [Combining demands for stable unfoldings]. +maxDmdEnv :: DmdEnv -> DmdEnv -> DmdEnv +maxDmdEnv (DE fv1 d1) (DE fv2 d2) = DE combined_fv combined_div + where + combined_fv = plusVarEnv_CD maxDmd fv1 (defaultFvDmd d1) fv2 (defaultFvDmd d2) + combined_div = lubDivergence d1 d2 + discardArgDmds :: DmdType -> DmdEnv discardArgDmds (DmdType fv _) = fv ===================================== testsuite/tests/dmdanal/should_compile/T18894.stderr ===================================== @@ -399,7 +399,8 @@ lvl :: (Int, Int) lvl = case $wg1 2# of { (# ww, ww #) -> (GHC.Types.I# ww, ww) } -- RHS size: {terms: 22, types: 16, coercions: 0, joins: 0/0} -$wh1 [InlPrag=[2]] :: GHC.Prim.Int# -> Int +$wh1 [InlPrag=[2], Dmd=LC(S,!P(L))] + :: GHC.Prim.Int# -> Int [LclId[StrictWorker([])], Arity=1, Str=<1L>, ===================================== testsuite/tests/dmdanal/should_run/M1.hs ===================================== @@ -0,0 +1,17 @@ +-- Short module name is essential, or else f doesn't inline +module M1 where +{-# INLINABLE [2] f #-} +f :: Int -> Int -> Float +f !dummy x = if times dummy 0 x == 1 + then 3.0 else 4.0 + +{-# INLINE [0] times #-} +times :: Int -> Int -> Int -> Int +times dummy 0 x = x `seq` ( 0 + big dummy ) +times _ a b = a * b + +{-# RULES "times" [1] forall dummy x. times dummy 0 x = 0 + big dummy #-} + +big :: Int -> Int +big x = succ . succ . succ . succ . succ . succ . succ . succ . succ $ x +{-# INLINE big #-} ===================================== testsuite/tests/dmdanal/should_run/T26416.hs ===================================== @@ -0,0 +1,3 @@ +module Main where +import M1 ( f ) +main = print (f 19 12) ===================================== testsuite/tests/dmdanal/should_run/T26416.stdout ===================================== @@ -0,0 +1 @@ +4.0 ===================================== testsuite/tests/dmdanal/should_run/all.T ===================================== @@ -35,3 +35,4 @@ test('T22549', normal, compile_and_run, ['-fdicts-strict -fno-specialise']) test('T23208', exit_code(1), multimod_compile_and_run, ['T23208_Lib', 'T23208']) test('T25439', normal, compile_and_run, ['']) test('T26748', normal, compile_and_run, ['']) +test('T26416', [extra_files(['M1.hs'])], multimod_compile_and_run, ['T26416','M1.hs']) ===================================== testsuite/tests/dmdanal/sigs/T21081.stderr ===================================== @@ -62,7 +62,7 @@ T21081.g: <ML> T21081.h: <MP(ML,ML)><1!P(1L)> T21081.h2: <L><1!P(SL)> T21081.i: <1L><1L><MP(ML,ML)> -T21081.j: <1!P(1L,1L)> +T21081.j: <S!P(1L,1L)> T21081.myfoldl: <LC(S,C(1,L))><1L><1L> T21081.snd': <1!P(A,1L)> View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/870243e4f2a24730539f01ee8e3f394… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/870243e4f2a24730539f01ee8e3f394… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/fendor/linkable-usage] 2 commits: Add linkable testsuite
by Hannes Siebenhandl (＠fendor) 12 Mar '26

12 Mar '26

Hannes Siebenhandl pushed to branch wip/fendor/linkable-usage at Glasgow Haskell Compiler / GHC Commits: 91ac3729 by fendor at 2026-03-12T12:15:18+01:00 Add linkable testsuite - - - - - f4b059f3 by fendor at 2026-03-12T12:45:12+01:00 Record `LinkableUsage` instead of `Linkable` in `LoaderState` Retaining a ByteCode `Linkable` after it has been loaded retains its `UnlinkedBCO`, keeping it alive for the remainder of the program. This starts accumulating a lot of `UnlinkedBCO` and memory over time. However, the `Linkable` is merely used to later record its usage in `mkObjectUsage`, which is used for recompilation checking. However, this is incorrect, as the interface file and bytecode objects could be in different states, e.g. the interface changes, but the bytecode library hasn't changed so we don't need to recompile and vice versa. By computing a `Fingerprint` for the `ModuleByteCode`, and recording it in the `LinkableUsage`, we know precisely whether the `ByteCode` object on disk is outdated. Thus, parts of this commit just makes sure that we efficiently compute a `Fingerprint` for `ModuleByteCode` and store it in the on-disk representation of `ModuleByteCode`. We change the `LoaderState` to retain `LinkableUsage`, which is smaller representation of a `Linkable`. This allows us to free the unneeded fields of `Linkable` after linking them. We declare the following memory invariants that this commit implements: * No `LinkablePart` should be retained from `LoaderState`. * `Linkable`s should be unloaded after they have been loaded. These invariants are unfortunately tricky to automatically uphold, so we are simply documenting our assumptions for now. ------------------------- Metric Increase: MultiLayerModulesTH_OneShot ------------------------- We allocate a bit more, but the peak number of bytes doesn't change. While a bit unfortunate, accepting the metric increase. We add multiple new performance measurements where we were able to observe the desired memory invariants. Further, we add regression tests to validate that the recompilation checker behaves more correct than before. - - - - - 32 changed files: - + compiler/GHC/ByteCode/Binary.hs - + compiler/GHC/ByteCode/Recomp/Binary.hs - compiler/GHC/ByteCode/Serialize.hs - compiler/GHC/Driver/Hooks.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Plugins.hs - compiler/GHC/HsToCore/Usage.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Iface/Recomp/Types.hs - compiler/GHC/Linker/ByteCode.hs - compiler/GHC/Linker/Deps.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Runtime/Loader.hs - compiler/GHC/Tc/Types.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Unit/Home/ModInfo.hs - compiler/GHC/Unit/Module/Deps.hs - compiler/GHC/Unit/Module/Status.hs - compiler/GHC/Utils/Binary.hs - compiler/ghc.cabal.in - ghc/GHCi/Leak.hs - + testsuite/tests/bytecode/TLinkable/BCOTemplate.hs - + testsuite/tests/bytecode/TLinkable/LinkableUsage01.stderr - + testsuite/tests/bytecode/TLinkable/Makefile - + testsuite/tests/bytecode/TLinkable/all.T - + testsuite/tests/bytecode/TLinkable/genLinkables.sh - + testsuite/tests/bytecode/TLinkable/linkable_bytecodelib.stdout - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/driver/multipleHomeUnits/multipleHomeUnits_recomp_th.stdout The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/90984c783669a2319052e749275741… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/90984c783669a2319052e749275741… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/26416] review
by Zubin (＠wz1000) 12 Mar '26

12 Mar '26

Zubin pushed to branch wip/26416 at Glasgow Haskell Compiler / GHC Commits: 63cec3b4 by Zubin Duggal at 2026-03-12T16:13:59+05:30 review - - - - - 2 changed files: - compiler/GHC/Core/Opt/DmdAnal.hs - compiler/GHC/Types/Demand.hs Changes: ===================================== compiler/GHC/Core/Opt/DmdAnal.hs ===================================== @@ -1111,8 +1111,17 @@ dmdAnalRhsSig top_lvl rec_flag env let_sd id rhs full_dmd_ty = addUnfoldingDemands env rhs_sd id rhs_dmd_ty DmdType full_rhs_env combined_rhs_dmds = full_dmd_ty - (final_rhs_dmds, final_rhs) = finaliseArgBoxities env id ww_arity - combined_rhs_dmds (de_div full_rhs_env) rhs' + final_rhs_dmds = finaliseArgBoxities env id ww_arity + combined_rhs_dmds (de_div full_rhs_env) rhs' + + -- Attach the final demands to the lambda binders of the RHS. + -- IMPORTANT: The lambda binders of final_rhs must carry the final demand + -- info, because worker/wrapper drives decisions from the idDemandInfo on + -- the lambdas (see mkWwstr_one), NOT from the strictness signature of the + -- function. So the demands must reflect both the unfolding combination + -- (from addUnfoldingDemands) and the boxity finalisation (from + -- finaliseArgBoxities). + final_rhs = set_lam_dmds final_rhs_dmds rhs' dmd_sig_arity = ww_arity + strictCallArity body_sd sig = mkDmdSigForArity dmd_sig_arity (DmdType sig_env final_rhs_dmds) @@ -2053,29 +2062,20 @@ positiveTopBudget (MkB n _) = n >= 0 finaliseArgBoxities :: AnalEnv -> Id -> Arity -> [Demand] -> Divergence - -> CoreExpr -> ([Demand], CoreExpr) + -> CoreExpr -> [Demand] -- POSTCONDITION: --- If: (dmds', rhs') = finaliseArgBoxitities ... dmds .. rhs +-- If: dmds' = finaliseArgBoxities ... dmds .. rhs -- Then: -- dmds' is the same as dmds (including length), except for boxity info --- rhs' is the same as rhs, except that the idDemandInfo on the outer --- lambda binders now includes the same finalised boxity info as dmds' -- NB: For join points, length dmds might be greater than ww_arity --- --- IMPORTANT: The lambda binders of rhs' must carry the final demand info, --- because worker/wrapper drives decisions from the idDemandInfo on the lambdas --- (see mkWwstr_one), NOT from the strictness signature of the function. --- So the demands must reflect both the unfolding combination (from --- addUnfoldingDemands) and the boxity finalisation done here. +-- NB: rhs is needed only to count visible binders. finaliseArgBoxities env fn ww_arity arg_dmds div rhs -- Check for an OPAQUE function: see Note [OPAQUE pragma] -- In that case, trim off all boxity info from argument demands - -- and demand info on lambda binders -- See Note [The OPAQUE pragma and avoiding the reboxing of arguments] | isOpaquePragma (idInlinePragma fn) - , let trimmed_arg_dmds = map trimBoxity arg_dmds - = (trimmed_arg_dmds, set_lam_dmds trimmed_arg_dmds rhs) + = map trimBoxity arg_dmds -- Check that we have enough visible binders to match the -- ww arity; if not, we won't do worker/wrapper @@ -2086,7 +2086,7 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs -- It's a bit of a corner case. Anyway for now we pass on the -- unadulterated demands from the RHS, without any boxity trimming. | ww_arity > count isId bndrs - = (arg_dmds, rhs) + = arg_dmds -- The normal case | otherwise @@ -2095,10 +2095,7 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs -- , text "max" <+> ppr max_wkr_args -- , text "dmds before:" <+> ppr (map idDemandInfo (filter isId bndrs)) -- , text "dmds after: " <+> ppr arg_dmds' ]) $ - (arg_dmds', set_lam_dmds arg_dmds' rhs) - -- set_lam_dmds: we must attach the final boxities to the lambda-binders - -- of the function, both because that's kosher, and because CPR analysis - -- uses the info on the binders directly. + arg_dmds' where opts = ae_opts env (bndrs, _body) = collectBinders rhs @@ -2186,18 +2183,18 @@ finaliseArgBoxities env fn ww_arity arg_dmds div rhs | positiveTopBudget bg_inner' = (bg_inner', dmd') | otherwise = (bg_inner, trimBoxity dmd) - set_lam_dmds :: [Demand] -> CoreExpr -> CoreExpr - -- Attach the demands to the outer lambdas of this expression - set_lam_dmds (dmd:dmds) (Lam v e) - | isTyVar v = Lam v (set_lam_dmds (dmd:dmds) e) - | otherwise = Lam (v `setIdDemandInfo` dmd) (set_lam_dmds dmds e) - set_lam_dmds dmds (Cast e co) = Cast (set_lam_dmds dmds e) co - -- This case happens for an OPAQUE function, which may look like - -- f = (\x y. blah) |> co - -- We give it strictness but no boxity (#22502) - set_lam_dmds _ e = e - -- In the OPAQUE case, the list of demands at this point might be - -- non-empty, e.g., when looking at a PAP. Hence don't panic (#22997). +set_lam_dmds :: [Demand] -> CoreExpr -> CoreExpr +-- Attach the demands to the outer lambdas of this expression +set_lam_dmds (dmd:dmds) (Lam v e) + | isTyVar v = Lam v (set_lam_dmds (dmd:dmds) e) + | otherwise = Lam (v `setIdDemandInfo` dmd) (set_lam_dmds dmds e) +set_lam_dmds dmds (Cast e co) = Cast (set_lam_dmds dmds e) co + -- This case happens for an OPAQUE function, which may look like + -- f = (\x y. blah) |> co + -- We give it strictness but no boxity (#22502) +set_lam_dmds _ e = e + -- In the OPAQUE case, the list of demands at this point might be + -- non-empty, e.g., when looking at a PAP. Hence don't panic (#22997). finaliseLetBoxity :: AnalEnv ===================================== compiler/GHC/Types/Demand.hs ===================================== @@ -874,10 +874,22 @@ because: * The optimised RHS may have had transformations applied that reveal strictness (e.g., inlining exposes a case on an argument). + Example: + RHS: x + Unfolding: head [x] + It's clear that the RHS is strict in `x`, but the demand analyser won't + spot that when it analyses the unfolding. * The optimised RHS may have had transformations applied that drop usage (e.g., a rewrite rule fires that doesn't use an argument, or a seq on a dictionary is dropped because dictionaries are known to terminate). + Example: + RHS: a + Unfolding: fst g + where `g` is in scope as `g = (a,b)`. + +See Note [Absence analysis for stable unfoldings and RULES] in +GHC.Core.Opt.DmdAnal for the broader context. When we inline the stable unfolding at a call site, we get the unfolding's behaviour, not the RHS's. So we must be conservative and combine the demands: @@ -894,9 +906,6 @@ behaviour, not the RHS's. So we must be conservative and combine the demands: So for cardinality bounds [l1..u1] from RHS and [l2..u2] from unfolding, we compute [max(l1,l2)..max(u1,u2)]. - -See Note [Absence analysis for stable unfoldings and RULES] in GHC.Core.Opt.DmdAnal -for the broader context. -} -- | Takes the maximum of both the lower and upper bound of two 'Card's. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/63cec3b4827d4ddaf3ec43aea15c619… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/63cec3b4827d4ddaf3ec43aea15c619… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/fendor/linkable-usage] Record `LinkableUsage` instead of `Linkable` in `LoaderState`
by Hannes Siebenhandl (＠fendor) 12 Mar '26

12 Mar '26

Hannes Siebenhandl pushed to branch wip/fendor/linkable-usage at Glasgow Haskell Compiler / GHC Commits: 90984c78 by fendor at 2026-03-12T11:21:36+01:00 Record `LinkableUsage` instead of `Linkable` in `LoaderState` Retaining a ByteCode `Linkable` after it has been loaded retains its `UnlinkedBCO`, keeping it alive for the remainder of the program. This starts accumulating a lot of `UnlinkedBCO` and memory over time. However, the `Linkable` is merely used to later record its usage in `mkObjectUsage`, which is used for recompilation checking. However, this is incorrect, as the interface file and bytecode objects could be in different states, e.g. the interface changes, but the bytecode library hasn't changed so we don't need to recompile and vice versa. By computing a `Fingerprint` for the `ModuleByteCode`, and recording it in the `LinkableUsage`, we know precisely whether the `ByteCode` object on disk is outdated. Thus, parts of this commit just makes sure that we efficiently compute a `Fingerprint` for `ModuleByteCode` and store it in the on-disk representation of `ModuleByteCode`. We change the `LoaderState` to retain `LinkableUsage`, which is smaller representation of a `Linkable`. This allows us to free the unneeded fields of `Linkable` after linking them. We declare the following memory invariants that this commit implements: * No `LinkablePart` should be retained from `LoaderState`. * `Linkable`s should be unloaded after they have been loaded. These invariants are unfortunately tricky to automatically uphold, so we are simply documenting our assumptions for now. ------------------------- Metric Increase: MultiLayerModulesTH_OneShot ------------------------- We allocate a bit more, but the peak number of bytes doesn't change. While a bit unfortunate, accepting the metric increase. We add multiple new performance measurements where we were able to observe the desired memory invariants. Further, we add regression tests to validate that the recompilation checker behaves more correct than before. - - - - - 33 changed files: - + compiler/GHC/ByteCode/Binary.hs - + compiler/GHC/ByteCode/Recomp/Binary.hs - compiler/GHC/ByteCode/Serialize.hs - compiler/GHC/Driver/Hooks.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Plugins.hs - compiler/GHC/HsToCore/Usage.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Iface/Recomp/Types.hs - compiler/GHC/Linker/ByteCode.hs - compiler/GHC/Linker/Deps.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Runtime/Loader.hs - compiler/GHC/Tc/Types.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Unit/Home/ModInfo.hs - compiler/GHC/Unit/Module/Deps.hs - compiler/GHC/Unit/Module/Status.hs - compiler/GHC/Utils/Binary.hs - compiler/ghc.cabal.in - ghc/GHCi/Leak.hs - + testsuite/ghc-config/ghc-config - + testsuite/tests/bytecode/TLinkable/BCOTemplate.hs - + testsuite/tests/bytecode/TLinkable/LinkableUsage01.stderr - + testsuite/tests/bytecode/TLinkable/Makefile - + testsuite/tests/bytecode/TLinkable/all.T - + testsuite/tests/bytecode/TLinkable/genLinkables.sh - + testsuite/tests/bytecode/TLinkable/linkable_bytecodelib.stdout - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/driver/multipleHomeUnits/multipleHomeUnits_recomp_th.stdout The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/90984c783669a2319052e7492757416… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/90984c783669a2319052e7492757416… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/fendor/linkable-usage] Record `LinkableUsage` instead of `Linkable` in `LoaderState`
by Hannes Siebenhandl (＠fendor) 12 Mar '26

12 Mar '26

Hannes Siebenhandl pushed to branch wip/fendor/linkable-usage at Glasgow Haskell Compiler / GHC Commits: 49560ff6 by fendor at 2026-03-12T11:14:29+01:00 Record `LinkableUsage` instead of `Linkable` in `LoaderState` Retaining a ByteCode `Linkable` after it has been loaded retains its `UnlinkedBCO`, keeping it alive for the remainder of the program. This starts accumulating a lot of `UnlinkedBCO` and memory over time. However, the `Linkable` is merely used to later record its usage in `mkObjectUsage`, which is used for recompilation checking. However, this is incorrect, as the interface file and bytecode objects could be in different states, e.g. the interface changes, but the bytecode library hasn't changed so we don't need to recompile and vice versa. By computing a `Fingerprint` for the `ModuleByteCode`, and recording it in the `LinkableUsage`, we know precisely whether the `ByteCode` object on disk is outdated. Thus, parts of this commit just makes sure that we efficiently compute a `Fingerprint` for `ModuleByteCode` and store it in the on-disk representation of `ModuleByteCode`. We change the `LoaderState` to retain `LinkableUsage`, which is smaller representation of a `Linkable`. This allows us to free the unneeded fields of `Linkable` after linking them. We declare the following memory invariants that this commit implements: * No `LinkablePart` should be retained from `LoaderState`. * `Linkable`s should be unloaded after they have been loaded. These invariants are unfortunately tricky to automatically uphold, so we are simply documenting our assumptions for now. ------------------------- Metric Increase: MultiLayerModulesTH_OneShot ------------------------- We allocate a bit more, but the peak number of bytes doesn't change. While a bit unfortunate, accepting the metric increase. We add multiple new performance measurements where we were able to observe the desired memory invariants. Further, we add regression tests to validate that the recompilation checker behaves more correct than before. - - - - - 33 changed files: - + compiler/GHC/ByteCode/Binary.hs - + compiler/GHC/ByteCode/Recomp/Binary.hs - compiler/GHC/ByteCode/Serialize.hs - compiler/GHC/Driver/Hooks.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Plugins.hs - compiler/GHC/HsToCore/Usage.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Iface/Recomp/Types.hs - compiler/GHC/Linker/ByteCode.hs - compiler/GHC/Linker/Deps.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Runtime/Loader.hs - compiler/GHC/Tc/Types.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Unit/Home/ModInfo.hs - compiler/GHC/Unit/Module/Deps.hs - compiler/GHC/Unit/Module/Status.hs - compiler/GHC/Utils/Binary.hs - compiler/ghc.cabal.in - ghc/GHCi/Leak.hs - + testsuite/ghc-config/ghc-config - + testsuite/tests/bytecode/TLinkable/BCOTemplate.hs - + testsuite/tests/bytecode/TLinkable/LinkableUsage01.stderr - + testsuite/tests/bytecode/TLinkable/Makefile - + testsuite/tests/bytecode/TLinkable/all.T - + testsuite/tests/bytecode/TLinkable/genLinkables.sh - + testsuite/tests/bytecode/TLinkable/linkable_bytecodelib.stdout - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/driver/multipleHomeUnits/multipleHomeUnits_recomp_th.stdout The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/49560ff60d39aa213944bd2af8af287… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/49560ff60d39aa213944bd2af8af287… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/stack-cloning-segfault] rts: forward clone-stack messages after TSO migration
by Matthew Pickering (＠mpickering) 12 Mar '26

12 Mar '26

Matthew Pickering pushed to branch wip/stack-cloning-segfault at Glasgow Haskell Compiler / GHC Commits: 5b296658 by Matthew Pickering at 2026-03-12T09:52:22+00:00 rts: forward clone-stack messages after TSO migration MSG_CLONE_STACK assumed that the target TSO was still owned by the capability that received the message. This is not always true: the TSO can migrate before the inbox entry is handled. When that happened, handleCloneStackMessage could clone a live stack from the wrong capability and use the wrong capability for allocation and performTryPutMVar, leading to stack sanity failures such as checkStackFrame: weird activation record found on stack. Fix this by passing the current capability into handleCloneStackMessage, rechecking msg->tso->cap at handling time, and forwarding the message if the TSO has migrated. Once ownership matches, use the executing capability consistently for cloneStack, rts_apply, and performTryPutMVar. Fixes #27008 - - - - - 5 changed files: - rts/CloneStack.c - rts/CloneStack.h - rts/Messages.c - testsuite/tests/rts/all.T - + testsuite/tests/rts/cloneThreadStackMigrating.hs Changes: ===================================== rts/CloneStack.c ===================================== @@ -84,15 +84,31 @@ void sendCloneStackMessage(StgTSO *tso, HsStablePtr mvar) { sendMessage(srcCapability, tso->cap, (Message *)msg); } -void handleCloneStackMessage(MessageCloneStack *msg){ - StgStack* newStackClosure = cloneStack(msg->tso->cap, msg->tso->stackobj); +// The cap argument is the capability which is handling the CloneStack message +void handleCloneStackMessage(Capability *cap, MessageCloneStack *msg){ + // We must check that the current owner of the thread we want to clone the stack for + // is still this capability. + Capability *owner = RELAXED_LOAD(&msg->tso->cap); + if (owner != cap) { + // The target TSO may have migrated after the message was queued on the old + // capability. In that case we must forward the request to the current + // owner; otherwise we would race with another capability mutating the + // stack while we clone it. + sendMessage(cap, owner, (Message *)msg); + return; + } + + // At this point the executing capability owns the TSO, so it is the only + // capability that may safely inspect the live stack and the one whose + // allocator we must use for the cloned StgStack closure. + StgStack* newStackClosure = cloneStack(cap, msg->tso->stackobj); // Lift StackSnapshot# to StackSnapshot by applying it's constructor. // This is necessary because performTryPutMVar() puts the closure onto the // stack for evaluation and stacks can not be evaluated (entered). - HaskellObj result = rts_apply(msg->tso->cap, StackSnapshot_constructor_closure, (HaskellObj) newStackClosure); + HaskellObj result = rts_apply(cap, StackSnapshot_constructor_closure, (HaskellObj) newStackClosure); - bool putMVarWasSuccessful = performTryPutMVar(msg->tso->cap, msg->result, result); + bool putMVarWasSuccessful = performTryPutMVar(cap, msg->result, result); if(!putMVarWasSuccessful) { barf("Can't put stack cloning result into MVar."); ===================================== rts/CloneStack.h ===================================== @@ -17,7 +17,7 @@ void sendCloneStackMessage(StgTSO *tso, HsStablePtr mvar); #include "BeginPrivate.h" #if defined(THREADED_RTS) -void handleCloneStackMessage(MessageCloneStack *msg); +void handleCloneStackMessage(Capability *cap, MessageCloneStack *msg); #endif #include "EndPrivate.h" ===================================== rts/Messages.c ===================================== @@ -135,7 +135,7 @@ loop: } else if(i == &stg_MSG_CLONE_STACK_info){ MessageCloneStack *cloneStackMessage = (MessageCloneStack*) m; - handleCloneStackMessage(cloneStackMessage); + handleCloneStackMessage(cap, cloneStackMessage); } else { ===================================== testsuite/tests/rts/all.T ===================================== @@ -587,6 +587,14 @@ test('cloneMyStack_retBigStackFrame', [req_c, extra_files(['cloneStackLib.c']), test('cloneThreadStack', [req_c, only_ways(['threaded1']), extra_ways(['threaded1']), extra_files(['cloneStackLib.c']), req_ghc_with_threaded_rts], compile_and_run, ['cloneStackLib.c -threaded']) +test('cloneThreadStackMigrating', + [ ignore_stdout + , only_ways(['threaded1']) + , extra_ways(['threaded1']) + , extra_run_opts('+RTS -N -DS -RTS') + , req_ghc_with_threaded_rts + ], compile_and_run, ['-threaded -debug -rtsopts']) + test('decodeMyStack', [ omit_ghci, js_broken(22261) # cloneMyStack# not yet implemented , when(ghc_with_ipe(), skip) # IPE builds can change decoded stack output. ===================================== testsuite/tests/rts/cloneThreadStackMigrating.hs ===================================== @@ -0,0 +1,37 @@ +module Main where + +import Control.Concurrent +import Control.Monad +import GHC.Exts.Stack +import GHC.Stack.CloneStack + +numWorkers :: Int +numWorkers = 100 + +startN :: Int +startN = 10 + +runForMicros :: Int +runForMicros = 1000000 + +fib :: Int -> Int +fib 0 = 1 +fib 1 = 1 +fib n = fib (n - 1) + fib (n - 2) + +workerThread :: Int -> IO () +workerThread n = do + fib n `seq` pure () + workerThread (n + 1) + +cloneThread :: ThreadId -> IO () +cloneThread tid = forever $ do + snapshot <- cloneThreadStack tid + stack <- decodeStack snapshot + stack `seq` pure () + +main :: IO () +main = do + tids <- replicateM numWorkers (forkIO $ workerThread startN) + mapM_ (forkIO . cloneThread) tids + threadDelay runForMicros View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/5b29665891ab33b218e3f6f5de4a7fc… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/5b29665891ab33b218e3f6f5de4a7fc… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T26878] Simplify mkTick
by sheaf (＠sheaf) 12 Mar '26

12 Mar '26

sheaf pushed to branch wip/T26878 at Glasgow Haskell Compiler / GHC Commits: b575e28a by Simon Peyton Jones at 2026-03-12T10:50:22+01:00 Simplify mkTick This commit simplifies 'GHC.Core.Utils.mkTick', removing the accumulating parameter 'rest' which was suspiciously treating a bunch of different ticks as a group, and moving the group as a whole around the AST, ignoring that the ticks in the group might have different placement properties. A few other changes are also implemented: - simplify 'can_split' predicate (no functional change) - drop profiling ticks around coercions, fixing #26941 - combine profiling ticks into one when possible Fixes #26878 and #26941 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 5 changed files: - compiler/GHC/Core/Utils.hs - compiler/GHC/Types/Tickish.hs - + testsuite/tests/simplCore/should_compile/T26941.hs - + testsuite/tests/simplCore/should_compile/T26941_aux.hs - testsuite/tests/simplCore/should_compile/all.T Changes: ===================================== compiler/GHC/Core/Utils.hs ===================================== @@ -303,59 +303,72 @@ mkCast expr co * * ********************************************************************* -} --- | Wraps the given expression in the source annotation, dropping the --- annotation if possible. +-- | Wraps the given expression in a Tick while respecting Tick invariants, +-- and performing small on-the-fly optimisations. +-- +-- Prefer using 'mkTick' over explicit use of the 'Tick' constructor. +-- +-- Small optimisations performed: +-- +-- * Minimise the AST covered by the tick, by pushing the tick deeper into +-- the expression if this doesn't change the semantics of the tick. +-- For example, push runtime relevant ticks through type applications +-- and type lambdas. +-- * Eliminate unnecessary ticks by either absorbing them into existing ones +-- or dropping them if that is valid (e.g. dropping profiling ticks around +-- types, coercions and literals). +-- * Split profiling ticks into counting/scoping parts so that the two parts +-- can be placed independently into the AST. mkTick :: CoreTickish -> CoreExpr -> CoreExpr -mkTick t orig_expr = mkTick' id orig_expr +mkTick t orig_expr = mkTick' orig_expr where -- Some ticks (cost-centres) can be split in two, with the -- non-counting part having laxer placement properties. - canSplit = tickishCanSplit t && tickishPlace (mkNoCount t) /= tickishPlace t + -- See Note [Scoping ticks and counting ticks] in GHC.Types.Tickish. + can_split = tickishCanSplit t - -- mkTick' handles floating of ticks *into* the expression. - mkTick' :: (CoreExpr -> CoreExpr) -- Apply before adding tick (float with) - -- Always a composition of (Tick t) wrappers - -> CoreExpr -- Current expression - -> CoreExpr - -- So in the call (mkTick' rest e), the expression - -- (rest e) - -- has the same type as e - -- Returns an expression equivalent to (Tick t (rest e)) - mkTick' rest expr = case expr of - -- Float ticks into unsafe coerce the same way we would do with a cast. - Case scrut bndr ty alts@[Alt ac abs _rhs] - | Just rhs <- isUnsafeEqualityCase scrut bndr alts - -> Case scrut bndr ty [Alt ac abs (mkTick' rest rhs)] + stop_here e = Tick t e -- Just wrap `t` around the current expression + -- That's the default option! - -- Cost centre ticks should never be reordered relative to each - -- other. Therefore we can stop whenever two collide. + -- mkTick' handles floating of tick `t` *into* the expression. + mkTick' :: CoreExpr -> CoreExpr + mkTick' expr = case expr of Tick t2 e - | ProfNote{} <- t2, ProfNote{} <- t -> Tick t $ rest expr - - -- Otherwise we assume that ticks of different placements float - -- through each other. - | tickishPlace t2 /= tickishPlace t -> Tick t2 $ mkTick' rest e + | ProfNote { profNoteCC = cc1, profNoteCount = cnt1, profNoteScope = scope1 } <- t + , ProfNote { profNoteCC = cc2, profNoteCount = cnt2, profNoteScope = scope2 } <- t2 + -> + -- Common up ticks with a shared cost centre. + -- Alas, if both ticks count, we are forced to retain both. + if cc1 == cc2 && (not cnt1 || not cnt2) + then + let t' = ProfNote { profNoteCC = cc1 + , profNoteCount = cnt1 || cnt2 + , profNoteScope = scope1 || scope2 + } + in mkTick t' e + else + -- Cost centre ticks for different cost centres should never be reordered + -- relative to each other. Therefore we can stop whenever two collide. + stop_here expr + + | tickishPlace t2 /= tickishPlace t + -> -- Otherwise, we assume that ticks of different + -- placements float through each other. + Tick t2 $ mkTick' e + + -- For source note ticks, this is where we make sure to + -- not introduce redundant ticks. + | tickishContains t t2 -> mkTick' e -- Drop t2 + | tickishContains t2 t -> expr -- Drop t - -- For annotations this is where we make sure to not introduce - -- redundant ticks. - | tickishContains t t2 -> mkTick' rest e -- Drop t2 - | tickishContains t2 t -> rest e -- Drop t - | otherwise -> mkTick' (rest . Tick t2) e - - -- Ticks don't care about types, so we just float all ticks - -- through them. Note that it's not enough to check for these - -- cases top-level. While mkTick will never produce Core with type - -- expressions below ticks, such constructs can be the result of - -- unfoldings. We therefore make an effort to put everything into - -- the right place no matter what we start with. - Cast e co -> mkCast (mkTick' rest e) co - Coercion co -> Tick t $ rest (Coercion co) + | otherwise + -> stop_here expr -- Always safe Lam x e -- Always float through type lambdas. Even for non-type lambdas, -- floating is allowed for all but the most strict placement rule. | not (isRuntimeVar x) || tickishPlace t /= PlaceRuntime - -> Lam x $ mkTick' rest e + -> Lam x $ mkTick' e -- If it is both counting and scoped, we split the tick into its -- two components, often allowing us to keep the counting tick on @@ -363,26 +376,41 @@ mkTick t orig_expr = mkTick' id orig_expr -- The point of this is that the counting tick can probably be -- floated, and the lambda may then be in a position to be -- beta-reduced. - | canSplit - -> Tick (mkNoScope t) $ rest $ Lam x $ mkTick (mkNoCount t) e + | can_split + -> Tick (mkNoScope t) $ Lam x $ mkTick (mkNoCount t) e App f arg -- Always float through type applications. | not (isRuntimeArg arg) - -> App (mkTick' rest f) arg + -> App (mkTick' f) arg -- We can also float through constructor applications, placement - -- permitting. Again we can split. - | isSaturatedConApp expr && (tickishPlace t==PlaceCostCentre || canSplit) + -- permitting. Again we can try splitting. + | isSaturatedConApp expr + , tickishPlace t == PlaceCostCentre || can_split -> if tickishPlace t == PlaceCostCentre - then rest $ tickHNFArgs t expr - else Tick (mkNoScope t) $ rest $ tickHNFArgs (mkNoCount t) expr + then tickHNFArgs t expr + else Tick (mkNoScope t) $ tickHNFArgs (mkNoCount t) expr + + -- Ticks don't care about types, so we just float all ticks + -- through them. Note that it's not enough to check for these + -- cases at the top-level. While mkTick will never produce Core with type + -- expressions below ticks, such constructs can be the result of + -- unfoldings. We therefore make an effort to put everything into + -- the right place no matter what we start with. + Cast e co -> mkCast (mkTick' e) co + + -- Float ticks into 'unsafeCoerce' the same way we would do with a cast. + Case scrut bndr ty alts@[Alt ac abs _rhs] + | Just rhs <- isUnsafeEqualityCase scrut bndr alts + -> Case scrut bndr ty [Alt ac abs (mkTick' rhs)] Var x - | notFunction && tickishPlace t == PlaceCostCentre - -> rest expr -- Drop t - | notFunction && canSplit - -> Tick (mkNoScope t) $ rest expr + | notFunction + , tickishPlace t == PlaceCostCentre || can_split + -> if tickishPlace t == PlaceCostCentre + then expr -- Drop tick t entirely + else Tick (mkNoScope t) expr where -- SCCs can be eliminated on variables provided the variable -- is not a function. In these cases the SCC makes no difference: @@ -392,12 +420,26 @@ mkTick t orig_expr = mkTick' id orig_expr -- when the function is called, so we must retain those. notFunction = not (isFunTy (idType x)) - Lit{} - | tickishPlace t == PlaceCostCentre - -> rest expr -- Drop t - - -- Catch-all: Annotate where we stand - _any -> Tick t $ rest expr + -- It doesn't make sense to wrap static data (such as coercions, types and literals) + -- in a tick which compiles to code, as the code will never be run. + -- + -- It is in fact actively harmful, because Core Lint will fail on a + -- coercion binding such as let co = <scc> (...), see #26941. + -- It makes more sense to discard the cost centre tick rather than weakening + -- Core Lint. + e@(Coercion {}) + | tickishIsCode t + -> e + e@(Type {}) + | tickishIsCode t + -> e + e@(Lit {}) + | tickishIsCode t + -> e + + -- Catch-all: annotate where we stand. + -- In particular (but not only): Let, most Cases. + _any -> Tick t expr mkTicks :: [CoreTickish] -> CoreExpr -> CoreExpr mkTicks ticks expr = foldr mkTick expr ticks ===================================== compiler/GHC/Types/Tickish.hs ===================================== @@ -261,6 +261,10 @@ Ticks have two independent attributes: See Note [Scoped ticks] +Note that profiling notes which both count and scope can be split into two +separate ticks, one that counts and doesn't scope and one that scopes and doesn't +count; see 'tickishCanSplit', 'mkNoCount' and 'mkNoScope'. + Note [Counting ticks] ~~~~~~~~~~~~~~~~~~~~ The following ticks count: @@ -451,7 +455,7 @@ data TickishPlacement = -- legal placement rule for counting ticks. -- NB: We generally try to move these as close to the relevant -- runtime expression as possible. This means they get pushed through - -- tyoe arguments. E.g. we create `(tick f) @Bool` instead of `tick (f @Bool)`. + -- type arguments. E.g. we create `(tick f) @Bool` instead of `tick (f @Bool)`. PlaceRuntime -- | As @PlaceRuntime@, but we float the tick through all ===================================== testsuite/tests/simplCore/should_compile/T26941.hs ===================================== @@ -0,0 +1,14 @@ +{-# LANGUAGE DataKinds #-} +{-# LANGUAGE GADTs #-} +{-# LANGUAGE TypeOperators #-} + +module T26941 where + +import GHC.TypeLits + +import T26941_aux ( SMayNat(SKnown), ListH, shxHead ) + +shsHead :: ListH (Just n : sh) Int -> SNat n +shsHead shx = + case shxHead shx of + SKnown SNat -> SNat ===================================== testsuite/tests/simplCore/should_compile/T26941_aux.hs ===================================== @@ -0,0 +1,20 @@ +{-# LANGUAGE DataKinds #-} +{-# LANGUAGE GADTs #-} +{-# LANGUAGE StandaloneKindSignatures #-} +{-# LANGUAGE TypeOperators #-} + +module T26941_aux where + +import Data.Kind +import GHC.TypeLits + +shxHead :: ListH (n : sh) i -> SMayNat i n +shxHead list = {-# SCC "bad_scc" #-} + ( case list of (i `ConsKnown` _) -> SKnown i ) + +type ListH :: [Maybe Nat] -> Type -> Type +data ListH sh i where + ConsKnown :: SNat n -> ListH sh i -> ListH (Just n : sh) i + +data SMayNat i n where + SKnown :: SNat n -> SMayNat i (Just n) ===================================== testsuite/tests/simplCore/should_compile/all.T ===================================== @@ -568,6 +568,8 @@ test('T26117', [grep_errmsg(r'==')], compile, ['-O -ddump-simpl -dsuppress-uniqu test('T26349', normal, compile, ['-O -ddump-rules']) test('T26681', normal, compile, ['-O']) +test('T26941', [extra_files(['T26941_aux.hs']), req_profiling], multimod_compile, ['T26941', '-v0 -O -prof']) + # T26709: we expect three `case` expressions not four test('T26709', [grep_errmsg(r'case')], multimod_compile, View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b575e28afb5d1dab8e2517445464409… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b575e28afb5d1dab8e2517445464409… You're receiving this email because of your account on gitlab.haskell.org.

1 0