[Git][ghc/ghc][wip/romes/12935] 6 commits: Deterministic Uniques in the NCG

Thu Sep 5 13:20:20 UTC 2024

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

Commits:
b9fcb459 by Rodrigo Mesquita at 2024-09-05T11:11:18+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

- - - - -
516769b7 by Rodrigo Mesquita at 2024-09-05T14:10:12+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

- - - - -
beb30330 by Rodrigo Mesquita at 2024-09-05T14:16:42+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.

- - - - -
901a7329 by Rodrigo Mesquita at 2024-09-05T14:16:42+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.

- - - - -
5c72dda0 by Rodrigo Mesquita at 2024-09-05T14:16:42+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).

- - - - -
8cef1175 by Rodrigo Mesquita at 2024-09-05T14:16:42+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:

- 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/BlockLayout.hs
- compiler/GHC/CmmToAsm/Dwarf.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/PPC/Instr.hs
- compiler/GHC/CmmToAsm/Reg/Graph.hs
- compiler/GHC/CmmToAsm/Reg/Graph/Spill.hs
- compiler/GHC/CmmToAsm/Reg/Linear.hs
- compiler/GHC/CmmToAsm/Reg/Linear/Base.hs

The diff was not included because it is too large.

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

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f446aa3cdaccc492d3ac1b07593e536b3d9590ef...8cef11755bce1655a1fe8384a8eb8b9897a26a8a
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/6d6ac1ab/attachment.html>