[Git][ghc/ghc][wip/T23490-part2] 17 commits: testsuite: Add support to capture performance metrics via 'perf'

Matthew Craven (@clyring) gitlab at gitlab.haskell.org
Fri Sep 6 21:28:14 UTC 2024



Matthew Craven pushed to branch wip/T23490-part2 at Glasgow Haskell Compiler / GHC


Commits:
a45f1488 by Fendor at 2024-09-04T20:22:00-04:00
testsuite: Add support to capture performance metrics via 'perf'

Performance metrics collected via 'perf' can be more accurate for
run-time performance than GHC's rts, due to the usage of hardware
counters.

We allow performance tests to also record PMU events according to 'perf
list'.

- - - - -
ce61fca5 by Fendor at 2024-09-04T20:22:00-04:00
gitlab-ci: Add nightly job for running the testsuite with perf profiling support

- - - - -
6dfb9471 by Fendor at 2024-09-04T20:22:00-04:00
Enable perf profiling for compiler performance tests

- - - - -
da306610 by sheaf at 2024-09-04T20:22:41-04:00
RecordCon lookup: don't allow a TyCon

This commit adds extra logic when looking up a record constructor.
If GHC.Rename.Env.lookupOccRnConstr returns a TyCon (as it may, due to
the logic explained in Note [Pattern to type (P2T) conversion]),
we emit an error saying that the data constructor is not in scope.

This avoids the compiler falling over shortly thereafter, in the call to
'lookupConstructorInfo' inside 'GHC.Rename.Env.lookupRecFieldOcc',
because the record constructor would not have been a ConLike.

Fixes #25056

- - - - -
9c354beb by Matthew Pickering at 2024-09-04T20:23:16-04:00
Use deterministic names for temporary files

When there are multiple threads they can race to create a temporary
file, in some situations the thread will create ghc_1.c and in some it
will create ghc_2.c. This filename ends up in the debug info for object
files after compiling a C file, therefore contributes to object
nondeterminism.

In order to fix this we store a prefix in `TmpFs` which serves to
namespace temporary files. The prefix is populated from the counter in
TmpFs when the TmpFs is forked. Therefore the TmpFs must be forked
outside the thread which consumes it, in a deterministic order, so each
thread always receives a TmpFs with the same prefix.

This assumes that after the initial TmpFs is created, all other TmpFs
are created from forking the original TmpFs. Which should have been try
anyway as otherwise there would be file collisions and non-determinism.

Fixes #25224

- - - - -
59906975 by Hécate Kleidukos at 2024-09-05T10:57:15-04:00
Silence x-partial in Haddock.Backends.Xhtml

This is an unfortunate consequence of two mechanisms:
  * GHC provides (possibly-empty) lists of names
  * The functions that retrieve those names are not equipped to do error
    reporting, and thus accept these lists at face value. They will have
    to be attached an effect for error reporting in a later refactoring

- - - - -
8afbab62 by Hécate Kleidukos at 2024-09-05T10:57:15-04:00
hadrian: Support loading haddock in ghci

There is one tricky aspect with wired-in packages where the boot package
is built with `-this-unit-id ghc` but the dependency is reported as
`-package-id ghc-9.6...`. This has never been fixed in GHC as the
situation of loading wired-in packages into the multi-repl seems like
quite a niche feature that is always just easier to workaround.

- - - - -
6cac9eb8 by Matthew Pickering at 2024-09-05T10:57:15-04:00
hadrian/multi: Load all targets when ./hadrian/ghci-multi is called

This seems to make a bit more sense than just loading `ghc` component
(and dependencies).

- - - - -
7d84df86 by Matthew Pickering at 2024-09-05T10:57:51-04:00
ci: Beef up determinism interface test

There have recently been some determinism issues with the simplifier and
documentation. We enable more things to test in the ABI test to check
that we produce interface files deterministically.

- - - - -
5456e02e by Sylvain Henry at 2024-09-06T11:57:01+02:00
Transform some StgRhsClosure into StgRhsCon after unarisation (#25166)

Before unarisation we may have code like:

  Test.foo :: Test.D
  [GblId, Unf=OtherCon []] =
      \u []
          case (# |_| #) [GHC.Types.(##)] of sat_sAw [Occ=Once1] {
          __DEFAULT -> Test.D [GHC.Types.True sat_sAw];
          };

After unarisation we get:

  Test.foo :: Test.D
  [GblId, Unf=OtherCon []] =
      {} \u [] Test.D [GHC.Types.True 2#];

Notice that it's still an Updatable closure for no reason anymore. This
patch transforms appropriate StgRhsClosures into StgRhsCons after
unarisation, allowing these closures to be statically allocated. Now we
get the expected:

  Test.foo :: Test.D
  [GblId, Unf=OtherCon []] =
      Test.D! [GHC.Types.True 2#];

Fix #25166

To avoid duplicating code, this patch refactors the mk(Top)StgRhs
functions and put them in a GHC.Stg.Make module alongside the new
mk(Top)StgRhsCon_maybe functions.

- - - - -
958b4518 by Hécate Kleidukos at 2024-09-06T16:40:56-04:00
haddock: Add missing requirements.txt for the online manual

- - - - -
fe7bbdae by Matthew Craven at 2024-09-06T17:20:44-04:00
Bump transformers submodule

The svg image files mentioned in transformers.cabal were
previously not checked in, which broke sdist generation.

- - - - -
60c9e5e7 by Matthew Craven at 2024-09-06T17:20:44-04:00
Remove reference to non-existent file in haddock.cabal

- - - - -
955f0e9c by Matthew Craven at 2024-09-06T17:20:45-04:00
Update hackage index state

- - - - -
c641d336 by Matthew Craven at 2024-09-06T17:20:45-04:00
Move tests T11462 and T11525 into tests/tcplugins

- - - - -
03bbabb8 by Matthew Craven at 2024-09-06T17:21:02-04:00
Repair the 'build-cabal' hadrian target

Fixes #23117. Fixes #23281. Fixes #23490.

This required:
 * Updating the bit-rotted compiler/Setup.hs and its setup-depends
 * Listing a few recently-added libraries and utilities
   in cabal.project-reinstall
 * Setting allow-boot-library-installs to 'True' since Cabal
   now considers the 'ghc' package itself a boot library for
   the purposes of this flag

Additionally, the allow-newer block in cabal.project-reinstall
was removed.  This block was probably added because when the
libraries/Cabal submodule is too new relative to the cabal-install
executable, solving the setup-depends for any package with a custom
setup requires building an old Cabal (from Hackage) against the
in-tree version of base, and this can fail un-necessarily due to
tight version bounds on base.  However, the blind allow-newer can
also cause the solver to go berserk and choose a stupid build plan
that has no business succeeding, and the failures when this happens
are dreadfully confusing. (See #23281 and #24363.)

Why does setup-depends solving insist on an old version of Cabal? See:
  https://github.com/haskell/cabal/blob/0a0b33983b0f022b9697f7df3a69358ee9061a89/cabal-install/src/Distribution/Client/ProjectPlanning.hs#L1393-L1410

The right solution here is probably to use the in-tree cabal-install
from libraries/Cabal/cabal-install with the build-cabal target rather
than whatever the environment happens to provide.  But this is left
for future work.

- - - - -
25d52bf9 by Matthew Craven at 2024-09-06T17:26:22-04:00
Revert "CI: Disable the test-cabal-reinstall job"

This reverts commit 38c3afb64d3ffc42f12163c6f0f0d5c414aa8255.

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- cabal.project-reinstall
- compiler/GHC/CoreToStg.hs
- compiler/GHC/Driver/Config/Stg/Pipeline.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Expr.hs
- + compiler/GHC/Stg/Make.hs
- compiler/GHC/Stg/Pipeline.hs
- compiler/GHC/Stg/Stats.hs
- compiler/GHC/Stg/Syntax.hs
- compiler/GHC/Stg/Unarise.hs
- compiler/GHC/Stg/Utils.hs
- compiler/GHC/StgToCmm/DataCon.hs
- compiler/GHC/Tc/Gen/Head.hs
- compiler/GHC/Tc/Utils/Env.hs
- compiler/GHC/Types/CostCentre.hs
- compiler/GHC/Utils/TmpFs.hs
- compiler/Setup.hs
- compiler/ghc.cabal.in
- hadrian/cabal.project
- hadrian/ghci-multi-cabal.in
- hadrian/src/Rules/ToolArgs.hs
- libraries/transformers
- testsuite/driver/perf_notes.py
- testsuite/driver/testglobals.py
- testsuite/driver/testlib.py


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a547477e49eb032a0d653c3c88f51fc3eca8171a...25d52bf9c59431642f27a7a9e49e65ea013c4cfb

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a547477e49eb032a0d653c3c88f51fc3eca8171a...25d52bf9c59431642f27a7a9e49e65ea013c4cfb
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/20240906/cc94d4ac/attachment-0001.html>


More information about the ghc-commits mailing list