[Git][ghc/ghc][wip/backports-9.8] 10 commits: Add changelog entry for renaming tuples from (,,...,,) to Tuple<n> (24291)

Zubin (@wz1000) gitlab at gitlab.haskell.org
Fri Feb 16 11:17:57 UTC 2024



Zubin pushed to branch wip/backports-9.8 at Glasgow Haskell Compiler / GHC


Commits:
46302091 by Andrei Borzenkov at 2024-02-16T16:45:13+05:30
Add changelog entry for renaming tuples from (,,...,,) to Tuple<n> (24291)

(cherry picked from commit 69abc7869bc504631e445083704115fc8a5d29c8)

- - - - -
ee1b0d6b by Zubin Duggal at 2024-02-16T16:45:13+05:30
ci: Allow release-hackage-lint to fail

Otherwise it blocks the ghcup metadata pipeline from running.

(cherry picked from commit 2e88063500d7ef33c83bd2de8ca5c7818ffbb026)

- - - - -
a5f67e14 by Ben Gamari at 2024-02-16T16:45:13+05:30
rts/EventLog: Place eliminate duplicate strlens

Previously many of the `post*` implementations would first compute the
length of the event's strings in order to determine the event length.
Later we would then end up computing the length yet again in
`postString`. Now we instead pass the string length to `postStringLen`,
avoiding the repeated work.

(cherry picked from commit 325b7613ebb2ca012a8969e20d35e95bfccc2bba)

- - - - -
ef2175bf by Ben Gamari at 2024-02-16T16:45:13+05:30
rts/eventlog: Place upper bound on IPE string field lengths

The strings in IPE events may be of unbounded length. Limit the lengths
of these fields to 64k characters to ensure that we don't exceed the
maximum event length.

(cherry picked from commit 8aafa51cb714fb16989089d4bc1ea7e7eb50124c)

- - - - -
941fa44b by Zubin Duggal at 2024-02-16T16:45:13+05:30
rts: drop unused postString function

(cherry picked from commit 0e60d52cc7e261da11c37bd649511584d92a688b)

- - - - -
91f12caf by Teo Camarasu at 2024-02-16T16:45:13+05:30
nonmoving: Add support for heap profiling

Add support for heap profiling while using the nonmoving collector.

We greatly simply the implementation by disabling concurrent collection for
GCs when heap profiling is enabled. This entails that the marked objects on
the nonmoving heap are exactly the live objects.

Note that we match the behaviour for live bytes accounting by taking the size
of objects on the nonmoving heap to be that of the segment's block
rather than the object itself.

Resolves #22221

(cherry picked from commit bedb4f0de102936099bda4e995cc83f1c344366c)

- - - - -
5287f3a1 by Simon Peyton Jones at 2024-02-16T16:45:13+05:30
Make decomposeRuleLhs a bit more clever

This fixes #24370 by making decomposeRuleLhs undertand
dictionary /functions/ as well as plain /dictionaries/

(cherry picked from commit ca2e919ecca35db412e772d7eadd6a7c4fb20e4b)

- - - - -
7065dd21 by ARATA Mizuki at 2024-02-16T16:45:13+05:30
Support 128-bit SIMD on AArch64 via LLVM backend

(cherry picked from commit 015886ec78e598f850c4202efdee239bac63b8c7)

- - - - -
485a63e2 by ARATA Mizuki at 2024-02-16T16:45:13+05:30
x86: Don't require -mavx2 when using 256-bit floating-point SIMD primitives

Fixes #24222

(cherry picked from commit 7d9a2e44e8cce00e24671325aebe47d9e529aee5)

- - - - -
4b2654cf by Ben Gamari at 2024-02-16T16:47:34+05:30
Fix thunk update ordering

Previously we attempted to ensure soundness of concurrent thunk update
by synchronizing on the access of the thunk's info table pointer field.
This was believed to be sufficient since the indirectee (which may
expose a closure allocated by another core) would not be examined
until the info table pointer update is complete.

However, it turns out that this can result in data races in the presence
of multiple threads racing a update a single thunk. For instance,
consider this interleaving under the old scheme:

            Thread A                             Thread B
            ---------                            ---------
    t=0     Enter t
      1     Push update frame
      2     Begin evaluation

      4     Pause thread
      5     t.indirectee=tso
      6     Release t.info=BLACKHOLE

      7     ... (e.g. GC)

      8     Resume thread
      9     Finish evaluation
      10    Relaxed t.indirectee=x

      11                                         Load t.info
      12                                         Acquire fence
      13                                         Inspect t.indirectee

      14    Release t.info=BLACKHOLE

Here Thread A enters thunk `t` but is soon paused, resulting in `t`
being lazily blackholed at t=6. Then, at t=10 Thread A finishes
evaluation and updates `t.indirectee` with a relaxed store.

Meanwhile, Thread B enters the blackhole. Under the old scheme this
would introduce an acquire-fence but this would only synchronize with
Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
visible to Thread B, introducing a data race.

We fix this by treating the `indirectee` field as we do all other
mutable fields. This means we must always access this field with
acquire-loads and release-stores.

See #23185.

(cherry picked from commit 9a52ae46a33b490161e1e3e1cc70caa46c60488a)
(cherry picked from commit 88afc6ea885d54523efbbb764f3435a147b799a5)

- - - - -


30 changed files:

- .gitlab-ci.yml
- compiler/CodeGen.Platform.h
- compiler/GHC.hs
- compiler/GHC/Cmm/CallConv.hs
- compiler/GHC/Core/Predicate.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/StgToCmm/Bind.hs
- compiler/GHC/StgToCmm/Prim.hs
- docs/users_guide/9.8.1-notes.rst
- libraries/base/changelog.md
- libraries/ghc-prim/changelog.md
- rts/Apply.cmm
- rts/Capability.h
- rts/Compact.cmm
- rts/Heap.c
- rts/Interpreter.c
- rts/Messages.c
- rts/PrimOps.cmm
- rts/ProfHeap.c
- rts/RtsFlags.c
- rts/StableName.c
- rts/StgMiscClosures.cmm
- rts/ThreadPaused.c
- rts/Threads.c
- rts/Updates.cmm
- rts/Updates.h
- rts/eventlog/EventLog.c
- rts/include/Cmm.h
- rts/include/rts/TSANUtils.h
- rts/include/stg/MachRegs.h


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c5623c31f5f798e7b8e05cc2ef55d3f77309fff9...4b2654cf13dcc6bed12589b84393711342781e8f

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c5623c31f5f798e7b8e05cc2ef55d3f77309fff9...4b2654cf13dcc6bed12589b84393711342781e8f
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/20240216/34a61dd8/attachment.html>


More information about the ghc-commits mailing list