[Git][ghc/ghc][master] 18 commits: cmm: Introduce MO_RelaxedRead

[Marge Bot (@marge-bot)]

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC


Commits:
31553b11 by Ben Gamari at 2024-02-01T12:21:29-05:00
cmm: Introduce MO_RelaxedRead

In hand-written Cmm it can sometimes be necessary to atomically load
from memory deep within an expression (e.g. see the `CHECK_GC` macro).
This MachOp provides a convenient way to do so without breaking the
expression into multiple statements.

- - - - -
0785cf81 by Ben Gamari at 2024-02-01T12:21:29-05:00
codeGen: Use relaxed accesses in ticky bumping

- - - - -
be423dda by Ben Gamari at 2024-02-01T12:21:29-05:00
base: use atomic write when updating timer manager

- - - - -
8a310e35 by Ben Gamari at 2024-02-01T12:21:29-05:00
Use relaxed atomics to manipulate TSO status fields

- - - - -
d6809ee4 by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Add necessary barriers when manipulating TSO owner

- - - - -
39e3ac5d by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Use `switch` to branch on why_blocked

This is a semantics-preserving refactoring.

- - - - -
515eb33d by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix synchronization on thread blocking state

We now use a release barrier whenever we update a thread's blocking
state. This required widening StgTSO.why_blocked as AArch64 does not
support atomic writes on 16-bit values.

- - - - -
eb38812e by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix data race in threadPaused

This only affects an assertion in the debug RTS and only needs relaxed
ordering.

- - - - -
26c48dd6 by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix data race in threadStatus#

- - - - -
6af43ab4 by Ben Gamari at 2024-02-01T12:21:29-05:00
rts: Fix data race in Interpreter's preemption check

- - - - -
9502ad3c by Ben Gamari at 2024-02-01T12:21:29-05:00
rts/Messages: Fix data race

- - - - -
60802db5 by Ben Gamari at 2024-02-01T12:21:30-05:00
rts/Prof: Fix data race

- - - - -
ef8ccef5 by Ben Gamari at 2024-02-01T12:21:30-05:00
rts: Use relaxed ordering on dirty/clean info tables updates

When changing the dirty/clean state of a mutable object we needn't have
any particular ordering.

- - - - -
76fe2b75 by Ben Gamari at 2024-02-01T12:21:30-05:00
codeGen: Use relaxed-read in closureInfoPtr

- - - - -
a6316eb4 by Ben Gamari at 2024-02-01T12:21:30-05:00
STM: Use acquire loads when possible

Full sequential consistency is not needed here.

- - - - -
6bddfd3d by Ben Gamari at 2024-02-01T12:21:30-05:00
rts: Use fence rather than redundant load

Previously we would use an atomic load to ensure acquire ordering.
However, we now have `ACQUIRE_FENCE_ON`, which allows us to express this
more directly.

- - - - -
55c65dbc by Ben Gamari at 2024-02-01T12:21:30-05:00
rts: Fix data races in profiling timer

- - - - -
856b5e75 by Ben Gamari at 2024-02-01T12:21:30-05:00
Add Note [C11 memory model]

- - - - -


30 changed files:

- compiler/GHC/Cmm/Expr.hs
- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/StgToCmm/Ticky.hs
- compiler/GHC/StgToCmm/Utils.hs
- libraries/base/src/GHC/Event/Thread.hs
- rts/Exception.cmm
- rts/HeapStackCheck.cmm
- rts/Interpreter.c
- rts/Messages.c
- rts/PrimOps.cmm
- rts/Proftimer.c
- rts/RaiseAsync.c
- rts/STM.c
- rts/Schedule.c
- rts/StgMiscClosures.cmm
- rts/StgStartup.cmm
- rts/ThreadPaused.c
- rts/Threads.c
- rts/TraverseHeap.c
- rts/include/Cmm.h
- rts/include/rts/storage/ClosureMacros.h


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/94ce031ddc84ee702c12a11793028ef21e65fa00...856b5e7561719ffce74595fca096082996163431

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/94ce031ddc84ee702c12a11793028ef21e65fa00...856b5e7561719ffce74595fca096082996163431
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/20240201/75f35db7/attachment-0001.html>