[Git][ghc/ghc][wip/romes/12935] 19 commits: rts: fix checkClosure error message

Rodrigo Mesquita (@alt-romes) gitlab at gitlab.haskell.org
Thu Sep 5 15:24:12 UTC 2024 


Rodrigo Mesquita pushed to branch wip/romes/12935 at Glasgow Haskell Compiler / GHC


Commits:
0d3bc2fa by Cheng Shao at 2024-09-04T07:20:06-04:00
rts: fix checkClosure error message

This patch fixes an error message in checkClosure() when the closure
has already been evacuated. The previous logic was meant to print the
evacuated closure's type in the error message, but it was completely
wrong, given info was not really an info table, but a tagged pointer
that points to the closure's new address.

- - - - -
fb0a4e5c by Sven Tennie at 2024-09-04T07:20:43-04:00
MO_AcquireFence: Less restrictive barrier

GCC and CLang translate the built-in `atomic_thread_fence(memory_order_acquire)`
to `dmb ishld`, which is a bit less restrictive than `dmb ish` (which
also implies stores.)

- - - - -
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.

- - - - -
4d5513cc by Matthew Pickering at 2024-09-05T16:21:46+01:00
Run on test-abi label

- - - - -
60afd1a2 by Rodrigo Mesquita at 2024-09-05T16:23:00+01:00
testsuite: Add a test for object determinism

Extends the abi_test with an object determinism check
Also includes a standalone test to be run by developers manually when
debugging issues with determinism.

- - - - -
e64683cd by Rodrigo Mesquita at 2024-09-05T16:24:01+01:00
Deterministic Uniques in the NCG

See Note [Deterministic Uniques in the NCG]

UniqDSM det uniques + use in Cmm.Info

Now for SRTs

SRT generation using deterministic uniq supply

Back LabelMap with deterministic UDFM

TSAN uniq rename hard

Revert "TSAN uniq rename hard"

This reverts commit 7ca5ab3036c15f38c6d4cbcb616d415958c6bcda.

improvements to uniqdsm

UniqDSM ProcPoint

CmmLayoutStack UniqDet

90% of cpsTop UniqDSM

Major progress in using UniqDSM in CmmToAsm and Ncg backends

Fix imports

Un-back label map with udfm

Revert "Un-back label map with udfm"

This reverts commit f5d2e4257214a3f7b7d845651e6662c5babfd6a3.

Make UDSM oneshot deriving via state

Fix -fllvm hang

- - - - -
ea273aaa by Rodrigo Mesquita at 2024-09-05T16:24:01+01:00
determinism: Cmm unique renaming pass

To achieve object determinism, we need to prevent the non-deterministic
uniques from leaking into the object code. We can do this by
deterministically renaming the non-external uniques in the Cmm groups
that are yielded right after StgToCmm.

The key to deterministic renaming is observing that the order of
declarations, instructions, and data in the Cmm groups are already
deterministic (modulo other determinism bugs), regardless of the
uniques. We traverse the Cmm AST in this deterministic order and
rename the uniques, incrementally, in the order they are found, thus
making them deterministic. This renaming is guarded by
-fobject-determinism which is disabled by default for now.

This is one of the key passes for object determinism. Read about the
overview of object determinism and a more detailed explanation of this
pass in:
* Note [Object determinism]
* Note [Renaming uniques deterministically]

Significantly closes the gap to #12935

- - - - -
f35cd9d7 by Rodrigo Mesquita at 2024-09-05T16:24:02+01:00
determinism: DCmmGroup vs CmmGroup

Part of our strategy in producing deterministic objects, namely,
renaming all Cmm uniques in order, depend on the object code produced
having a deterministic order (say, A_closure always comes before
B_closure).

However, the use of LabelMaps in the Cmm representation invalidated this
requirement because the LabelMaps elements would already be in a
non-deterministic order (due to the original uniques), and the renaming
in sequence wouldn't work because of that non-deterministic order.

Therefore, we now start off with lists in CmmGroup (which preserve the
original order), and convert them into LabelMaps (for performance in the
code generator) after the uniques of the list elements have been
renamed.

See Note [DCmmGroup vs CmmGroup or: Deterministic Info Tables] and #12935.

- - - - -
2dbda747 by Rodrigo Mesquita at 2024-09-05T16:24:02+01:00
determinism: Don't print unique in pprFullName

This unique was leaking as part of the profiling description in info
tables when profiling was enabled, despite not providing information
relevant to the profile.

- - - - -
5306bdf2 by Rodrigo Mesquita at 2024-09-05T16:24:02+01:00
determinism: UDFM for distinct-constructor-tables

In order to produce deterministic objects when compiling with
-distinct-constructor-tables, we also have to update the data
constructor map to be backed by a deterministic unique map (UDFM) rather
than a non-deterministic one (UniqMap).

- - - - -
0e766d8e by Rodrigo Mesquita at 2024-09-05T16:24:02+01:00
determinism: Rename CmmGroups in generateCgIPEStub

Make sure to also deterministically rename the IPE Cmm (as per Note
[Renaming uniques deterministically]) to guarantee deterministic objects
when IPE information is requested.

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/GHC/Cmm.hs
- compiler/GHC/Cmm/BlockId.hs
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Dataflow.hs
- compiler/GHC/Cmm/Dataflow/Graph.hs
- compiler/GHC/Cmm/Graph.hs
- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/Info/Build.hs
- compiler/GHC/Cmm/LayoutStack.hs
- compiler/GHC/Cmm/Opt.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/Pipeline.hs
- compiler/GHC/Cmm/ProcPoint.hs
- compiler/GHC/Cmm/Reducibility.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/Cmm/Switch.hs
- compiler/GHC/Cmm/Switch/Implement.hs
- compiler/GHC/Cmm/ThreadSanitizer.hs
- + compiler/GHC/Cmm/UniqueRenamer.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CmmToAsm/BlockLayout.hs
- compiler/GHC/CmmToAsm/Dwarf.hs
- compiler/GHC/CmmToAsm/Monad.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8cef11755bce1655a1fe8384a8eb8b9897a26a8a...0e766d8eb501a9f37802d119777117e361e09649

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8cef11755bce1655a1fe8384a8eb8b9897a26a8a...0e766d8eb501a9f37802d119777117e361e09649
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/20240905/0f49280e/attachment-0001.html>

More information about the ghc-commits mailing list