Hannes Siebenhandl pushed to branch wip/fendor/hpc-bc-support at Glasgow Haskell Compiler / GHC Commits: d419e972 by Luite Stegeman at 2026-04-13T15:16:04-04:00 Suppress desugaring warnings in the pattern match checker Avoid duplicating warnings from the actual desugaring pass. fixes #25996 - - - - - c5b80dd0 by Phil de Joux at 2026-04-13T15:16:51-04:00 Typo ~/ghc/arch-os-version/environments - - - - - 71462fff by Luite Stegeman at 2026-04-13T15:17:38-04:00 add changelog entry for #26233 - - - - - d1ddfd4b by Rodrigo Mesquita at 2026-04-14T18:41:12-04:00 Add test for #25636 The existing test behaviour of "T23146_liftedeq" changed because the simplifier now does a bit more inlining. We can restore the previous bad behavior by using an OPAQUE pragma. This test doubles as a test for #25636 when run in ghci, so we add it as such. - - - - - b9df40ee by Rodrigo Mesquita at 2026-04-14T18:41:12-04:00 refactor: protoBCOName is always a Name Simplifies the code by removing the unnecessary type argument to ProtoBCO which was always 'Name' - - - - - 5c2a179e by Rodrigo Mesquita at 2026-04-14T18:41:12-04:00 Allocate static constructors for bytecode This commit adds support for static constructors when compiling and linking ByteCode objects. Top-level StgRhsCon get lowered to ProtoStaticCons rather than to ProtoBCOs. A ProtoStaticCon gets allocated directly as a data con application on the heap (using the new primop newConApp#). Previously, we would allocate a ProtoBCO which, when evaluated, would PACK and return the constructor. A few more details are given in Note [Static constructors in Bytecode]. Secondly, this commit also fixes issue #25636 which was caused by linking *unlifted* constructors in BCO instructions as - (1) a thunk indexing the array of BCOs in a module - (2) which evaluated to a BCO which still had to be evaluated to return the unlifted constructor proper. The (2) issue has been resolved by allocating the static constructors directly. The (1) issue can be resolved by ensuring that we allocate all unlifted top-level constructors eagerly, and leave the knot-tying for the lifted BCOs and top-level constructors only. The top-level unlifted constructors are never mutually recursive, so we can allocate them all in one go as long as we do it in topological order. Lifted fields of unlifted constructors can still be filled by the knot-tied lifted variables since in those fields it is fine to keep those thunks. See Note [Tying the knot in createBCOs] for more details. Fixes #25636 ------------------------- Metric Decrease: LinkableUsage01 ------------------------- - - - - - cde47053 by Rodrigo Mesquita at 2026-04-14T18:41:12-04:00 Revert "StgToByteCode: Assert that PUSH_G'd values are lifted" This reverts commit ec26c54d818e0cd328276196930313f66b780905. Ever since f7a22c0f4e9ae0dc767115d4c53fddbd8372b777, we now do support and will link top-level unlifted constructors into evaluated and properly tagged values which we can reference with PUSH_G. This assertion is no longer true and triggered a failure in T25636 - - - - - c7a7e5b8 by Rodrigo Mesquita at 2026-04-14T18:41:12-04:00 refactor: Tag more remote Ptrs as RemotePtr Pure refactor which improves the API of - GHC.ByteCode.Linker - GHC.Runtime.Interpreter - GHC.Runtime.Interpreter.Types.SymbolCache by using `RemotePtr` for more functions which used to return `Ptr`s that could potentially be in a foreign process. E.g. `lookupIE`, `lookupStaticPtr`, etc... - - - - - fc59494c by Rodrigo Mesquita at 2026-04-14T18:41:12-04:00 Add float# and subword tests for #25636 These tests cover that static constructors in bytecode work correctly for Float# and subword values (Word8#, Word16#) - - - - - 477f521b by Rodrigo Mesquita at 2026-04-14T18:41:12-04:00 test: Validate topoSort logic in createBCOs This test validates that the topological sorting and ordering of the unlifted constructors and lifted constructors in `createBCOs` is correct. See `Note [Tying the knot in createBCOs]` for why tying the knot for the created BCOs is slightly difficult and why the topological sorting is necessary. This test fails when `let topoSortedObjs = topSortObjs objs` is substituted by `let topoSortedObjs = zip [0..] objs`, thus witnessing the toposort logic is correct and necessary. The test calls the ghci `createBCOs` directly because it is currently impossible to construct in Source Haskell a situation where a top-level static unlifted constructor depends on another (we don't have top-level unlifted constructors except for nullary constructors like `Leaf :: (UTree :: UnliftedType)`). This is another test for fix for #25636 - - - - - 2d9c30be by Simon Jakobi at 2026-04-14T18:42:00-04:00 Improve tests for `elem` ...in order to simplify the work on #27096. * Improve T17752 by including the Core output in golden files, checking both -O1 and -O2. * Add tests for fusion and no-fusion cases. Fixes #27101. - - - - - 909d52a4 by fendor at 2026-04-15T11:45:50+02:00 Expose startupHpc as an rts symbol - - - - - 1ff995c5 by fendor at 2026-04-15T11:48:16+02:00 Make HPC work with bytecode interpreter Add support to generate .tix files from bytecode objects and the bytecode interpreter. Conceptually, we insert HPC ticks into the bytecode similar to how we insert breakpoints. HPC and breakpoints do not share the same tick array but we use a separate tick-array for hpc/breakpoint ticks during bytecode generation. We teach the bytecode interpreter to handle hpc ticks. The implementation is quite trivial, simply increment the counter in the global hpc_ticks array for the respective module. This hpc_ticks array is generated as part of the `CStub`, so we can rely on it existing. A tricky bit is "registering" a bytecode object for HPC instrumentation. In the compiled case, this is achieved via CStub and initializer/finalizers `.init` sections which are called when the executable is run. After the initializers have been invoked, which is before `hs_init_ghc`, we then call `startup_hpc` in `hs_init_ghc` iff any modules were "registered" for hpc instrumentation via `hs_hpc_module`. Since bytecode objects are loaded after starting up GHCi, this workflow doesn't work for supporting `hpc` and the `hpc` run-time is never started, even if a module is added for instrumentation. We fix this issue by employing the same technique as is for `SptEntry`s: * We introduce a new field to `CompiledByteCode`, called `ByteCodeHpcInfo` which contains enough information to call `hs_hpc_module`, allowing us to register the module for `hpc` instrumentation`. * After registering the module, we unconditionally call `startupHpc`, to make sure the .tix file is written. Calling `startupHpc` multiple times is safe. Calling `hs_hpc_module` multiple times for the same module is also safe. If we didn't register the hpc module in this way, evaluating a bytecode object instrumented with `-fhpc` without registering it in the `hpc` run-time will simply not generate any `.tix` files for this bytecode object. However, this shouldn't happen if everything is set up correctly. Closes #27036 - - - - - 118 changed files: - + changelog.d/T25636 - + changelog.d/bytecode-interpreter-hpc-support - + changelog.d/fix-duplicate-pmc-warnings - + changelog.d/fix-ghci-duplicate-warnings-26233 - compiler/GHC/Builtin/primops.txt.pp - compiler/GHC/ByteCode/Asm.hs - compiler/GHC/ByteCode/Binary.hs - compiler/GHC/ByteCode/Instr.hs - compiler/GHC/ByteCode/Linker.hs - compiler/GHC/ByteCode/Types.hs - compiler/GHC/Cmm/Liveness.hs - compiler/GHC/Driver/Backend.hs - compiler/GHC/Driver/CodeOutput.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/HsToCore.hs - compiler/GHC/HsToCore/Coverage.hs - compiler/GHC/HsToCore/Pmc/Desugar.hs - compiler/GHC/HsToCore/Ticks.hs - compiler/GHC/Iface/Tidy.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Runtime/Interpreter.hs - compiler/GHC/Runtime/Interpreter/Types/SymbolCache.hs - compiler/GHC/StgToByteCode.hs - compiler/GHC/StgToCmm/DataCon.hs - compiler/GHC/StgToCmm/Layout.hs - compiler/GHC/StgToCmm/Prim.hs - compiler/GHC/StgToJS/Prim.hs - compiler/GHC/Types/HpcInfo.hs - compiler/GHC/Unit/Module/ModGuts.hs - docs/users_guide/packages.rst - + libraries/base/tests/perf/ElemFusionUnknownList.hs - + libraries/base/tests/perf/ElemFusionUnknownList_O1.stderr - + libraries/base/tests/perf/ElemFusionUnknownList_O2.stderr - + libraries/base/tests/perf/ElemNoFusion.hs - + libraries/base/tests/perf/ElemNoFusion_O1.stderr - + libraries/base/tests/perf/ElemNoFusion_O2.stderr - − libraries/base/tests/perf/Makefile - libraries/base/tests/perf/T17752.hs - − libraries/base/tests/perf/T17752.stdout - + libraries/base/tests/perf/T17752_O1.stderr - + libraries/base/tests/perf/T17752_O2.stderr - libraries/base/tests/perf/all.T - + libraries/ghci/GHCi/Coverage.hs - libraries/ghci/GHCi/CreateBCO.hs - libraries/ghci/GHCi/Message.hs - libraries/ghci/GHCi/ResolvedBCO.hs - libraries/ghci/GHCi/Run.hs - libraries/ghci/ghci.cabal.in - rts/Disassembler.c - rts/Hpc.c - rts/Interpreter.c - rts/PrimOps.cmm - rts/RtsSymbols.c - rts/include/Rts.h - rts/include/rts/Bytecodes.h - rts/include/rts/storage/ClosureMacros.h - rts/include/stg/MiscClosures.h - testsuite/tests/codeGen/should_run/T23146/T23146_liftedeq.hs - + testsuite/tests/codeGen/should_run/T23146/T25636.script - + testsuite/tests/codeGen/should_run/T23146/T25636.stdout - testsuite/tests/codeGen/should_run/T23146/all.T - + testsuite/tests/codeGen/should_run/T25636a/T25636a.script - + testsuite/tests/codeGen/should_run/T25636a/T25636a.stdout - + testsuite/tests/codeGen/should_run/T25636a/all.T - + testsuite/tests/codeGen/should_run/T25636b/T25636b.script - + testsuite/tests/codeGen/should_run/T25636b/T25636b.stdout - + testsuite/tests/codeGen/should_run/T25636b/all.T - + testsuite/tests/codeGen/should_run/T25636c/T25636c.script - + testsuite/tests/codeGen/should_run/T25636c/T25636c.stdout - + testsuite/tests/codeGen/should_run/T25636c/all.T - + testsuite/tests/codeGen/should_run/T25636d/T25636d.script - + testsuite/tests/codeGen/should_run/T25636d/T25636d.stdout - + testsuite/tests/codeGen/should_run/T25636d/all.T - + testsuite/tests/codeGen/should_run/T25636e/T25636e.script - + testsuite/tests/codeGen/should_run/T25636e/T25636e.stdout - + testsuite/tests/codeGen/should_run/T25636e/all.T - + testsuite/tests/deSugar/should_compile/T25996.hs - + testsuite/tests/deSugar/should_compile/T25996.stderr - testsuite/tests/deSugar/should_compile/all.T - testsuite/tests/ghci.debugger/scripts/print034.stdout - + testsuite/tests/ghci/should_run/T25636f.hs - + testsuite/tests/ghci/should_run/T25636f.stdout - testsuite/tests/ghci/should_run/all.T - testsuite/tests/hpc/Makefile - testsuite/tests/hpc/T17073.stdout → testsuite/tests/hpc/T17073a.stdout - + testsuite/tests/hpc/T17073b.stdout - testsuite/tests/hpc/T20568.stdout → testsuite/tests/hpc/T20568a.stdout - + testsuite/tests/hpc/T20568b.stdout - testsuite/tests/hpc/all.T - testsuite/tests/hpc/fork/Makefile - testsuite/tests/hpc/function/Makefile - testsuite/tests/hpc/function/test.T - + testsuite/tests/hpc/function/tough1.stderr - + testsuite/tests/hpc/function/tough1.stdout - testsuite/tests/hpc/function2/test.T - + testsuite/tests/hpc/function2/tough3.script - + testsuite/tests/hpc/ghc_ghci/BytecodeMain.hs - testsuite/tests/hpc/ghc_ghci/Makefile - + testsuite/tests/hpc/ghc_ghci/hpc_ghc_ghci_bytecode.stdout - testsuite/tests/hpc/ghc_ghci/test.T - testsuite/tests/hpc/hpcrun.pl - testsuite/tests/hpc/simple/Makefile - + testsuite/tests/hpc/simple/hpc002.hs - + testsuite/tests/hpc/simple/hpc002.stdout - + testsuite/tests/hpc/simple/hpc003.hs - + testsuite/tests/hpc/simple/hpc003.script - + testsuite/tests/hpc/simple/hpc003.stdout - testsuite/tests/hpc/simple/test.T - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/interface-stability/base-exports.stdout-ws-32 - testsuite/tests/interface-stability/ghc-experimental-exports.stdout - testsuite/tests/interface-stability/ghc-experimental-exports.stdout-mingw32 - testsuite/tests/interface-stability/ghc-prim-exports.stdout - testsuite/tests/interface-stability/ghc-prim-exports.stdout-mingw32 - utils/deriveConstants/Main.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d9e7c293fd582df0b24b40c024b8644... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d9e7c293fd582df0b24b40c024b8644... You're receiving this email because of your account on gitlab.haskell.org.