[Git][ghc/ghc][wip/ghc-9.4.5-backports] 14 commits: Add test for T23184

Zubin (@wz1000) gitlab at gitlab.haskell.org
Tue Apr 11 06:25:28 UTC 2023 


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


Commits:
d73ba44f by Matthew Pickering at 2023-04-11T11:55:10+05:30
Add test for T23184

There was an outright bug, which Simon fixed in July 2021, as a little side-fix on a complicated patch:

```
commit 6656f0165a30fc2a22208532ba384fc8e2f11b46
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Fri Jul 23 23:57:01 2021 +0100

    A bunch of changes related to eta reduction

    This is a large collection of changes all relating to eta
    reduction, originally triggered by #18993, but there followed
    a long saga.

    Specifics:

...lots of lines omitted...

    Other incidental changes

    * Fix a fairly long-standing outright bug in the ApplyToVal case of
      GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
      tail of 'dmds' in the recursive call, which meant the demands were All
      Wrong.  I have no idea why this has not caused problems before now.
```

Note this "Fix a fairly longstanding outright bug".   This is the specific fix
```
@@ -3552,8 +3556,8 @@ mkDupableContWithDmds env dmds
         --              let a = ...arg...
         --              in [...hole...] a
         -- NB: sc_dup /= OkToDup; that is caught earlier by contIsDupable
-    do  { let (dmd:_) = dmds   -- Never fails
-        ; (floats1, cont') <- mkDupableContWithDmds env dmds cont
+    do  { let (dmd:cont_dmds) = dmds   -- Never fails
+        ; (floats1, cont') <- mkDupableContWithDmds env cont_dmds cont
         ; let env' = env `setInScopeFromF` floats1
         ; (_, se', arg') <- simplArg env' dup se arg
         ; (let_floats2, arg'') <- makeTrivial env NotTopLevel dmd (fsLit "karg") arg'
```
Ticket #23184 is a report of the bug that this diff fixes.

(cherry picked from commit d97354a82b6f79c4d9a4d389fafdd94375454f59)

- - - - -
f5322d7d by Matthew Pickering at 2023-04-11T11:55:10+05:30
Backport fix to #23184 to 9.4

This backports the fix suggested in #23184 to GHC-9.4

It is from the larger patch (!7861):

 ```
commit 6656f0165a30fc2a22208532ba384fc8e2f11b46
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Fri Jul 23 23:57:01 2021 +0100

    A bunch of changes related to eta reduction

    This is a large collection of changes all relating to eta
    reduction, originally triggered by #18993, but there followed
    a long saga.

    Specifics:

...lots of lines omitted...

    Other incidental changes

    * Fix a fairly long-standing outright bug in the ApplyToVal case of
      GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
      tail of 'dmds' in the recursive call, which meant the demands were All
      Wrong.  I have no idea why this has not caused problems before now.
```

(cherry picked from commit d2dee3f82dcfdfc49cfb708222bb78aea0713cd6)

- - - - -
998f537b by Ben Gamari at 2023-04-11T11:55:10+05:30
rts: Don't rely on EXTERN_INLINE for slop-zeroing logic

Previously we relied on calling EXTERN_INLINE functions defined in
ClosureMacros.h from Cmm to zero slop. However, as far as I can tell,
this is no longer safe to do in C99 as EXTERN_INLINE definitions may be emitted
in each compilation unit.

Fix this by explicitly declaring a new set of non-inline functions in
ZeroSlop.c which can be called from Cmm and marking the ClosureMacros.h
definitions as INLINE_HEADER.

In the future we should try to eliminate EXTERN_INLINE.

(cherry picked from commit c6ec4cd1a94a1b76b7b094d5c92ee605031ecf60)

- - - - -
74397df1 by Ben Gamari at 2023-04-11T11:55:11+05:30
rts: Fix capability-count check in zeroSlop

Previously `zeroSlop` examined `RtsFlags` to determine whether the
program was single-threaded. This is wrong; a program may be started
with `+RTS -N1` yet the process may later increase the capability count
with `setNumCapabilities`. This lead to quite subtle and rare crashes.

Fixes #23088.

(cherry picked from commit c32abd4b936b3dfc61974ed5915c330fe7ed10d5)

- - - - -
917b9314 by Ben Gamari at 2023-04-11T11:55:11+05:30
nonmoving: Disable slop-zeroing

As noted in #23170, the nonmoving GC can race with a mutator zeroing the
slop of an updated thunk (in much the same way that two mutators would
race). Consequently, we must disable slop-zeroing when the nonmoving GC
is in use.

Closes #23170

(cherry picked from commit d1bb16ed3e18a4f41fcfe31f0bf57dbaf589d6c5)

- - - - -
aa27169d by Simon Peyton Jones at 2023-04-11T11:55:11+05:30
Take more care with unlifted bindings in the specialiser

As #22998 showed, we were floating an unlifted binding to top
level, which breaks a Core invariant.

The fix is easy, albeit a little bit conservative.  See
Note [Care with unlifted bindings] in GHC.Core.Opt.Specialise

(cherry picked from commit 7192ef91c855e1fae6997f75cfde76aafd0b4bcf)

- - - - -
1e6a6302 by Simon Peyton Jones at 2023-04-11T11:55:11+05:30
Make FloatIn robust to shadowing

This MR fixes #22622. See the new
  Note [Shadowing and name capture]

I did a bit of refactoring in sepBindsByDropPoint too.

The bug doesn't manifest in HEAD, but it did show up in 9.4,
so we should backport this patch to 9.4

(cherry picked from commit 6206cb9287f3f6e70c669660a646a65274870d2b)

- - - - -
9025be6f by Simon Peyton Jones at 2023-04-11T11:55:11+05:30
Fix void-arg-adding mechanism for worker/wrapper

As #22725 shows, in worker/wrapper we must add the void argument
/last/, not first.  See GHC.Core.Opt.WorkWrap.Utils
Note [Worker/wrapper needs to add void arg last].

That led me to to study GHC.Core.Opt.SpecConstr
Note [SpecConstr needs to add void args first] which suggests the
opposite!  And indeed I think it's the other way round for SpecConstr
-- or more precisely the void arg must precede the "extra_bndrs".

That led me to some refactoring of GHC.Core.Opt.SpecConstr.calcSpecInfo.

(cherry picked from commit 964284fcab6e27fe2fa5c279ea008551cbc15dbb)

- - - - -
f7ec8dc5 by Ben Gamari at 2023-04-11T11:55:11+05:30
rts: Statically assert alignment of Capability

In #22965 we noticed that changes in the size of `Capability` can result
in unsound behavior due to the `align` pragma claiming an alignment
which we don't in practice observe. Avoid this by statically asserting
that the size is a multiple of the alignment.

(cherry picked from commit db83f8bbf2e0ac68df675dea6b716fb7c19c649a)

- - - - -
3ba0de7d by Ben Gamari at 2023-04-11T11:55:11+05:30
rts: Introduce getNumCapabilities

And ensure accesses to n_capabilities are atomic (although with relaxed
ordering). This is necessary as RTS API callers may concurrently call
into the RTS without holding a capability.

(cherry picked from commit 70999283156f527c5aea6dee57a3d14989a9903a)

- - - - -
0c3b31a0 by Ben Gamari at 2023-04-11T11:55:11+05:30
rts: Introduce stgMallocAlignedBytes

(cherry picked from commit 5f7a4a6d8311d2faa9c90b2b0c4431dd4427839d)

- - - - -
d3af633b by Ben Gamari at 2023-04-11T11:55:11+05:30
rts: Correctly align Capability allocations

Previously we failed to tell the C allocator that `Capability`s needed
to be aligned, resulting in #22965.

Fixes #22965.
Fixes #22975.

(cherry picked from commit 8a6f745d963fc9b79c7b1e4b477f4fc724233655)

- - - - -
616ca622 by Ben Gamari at 2023-04-11T11:55:11+05:30
rts: Drop no-alignment special case for Windows

For reasons that aren't clear, we were previously not giving Capability
the same favorable alignment on Windows that we provided on other
platforms. Fix this.

(cherry picked from commit 5464c73f192f76e75160e8992fe9720d943ae611)

- - - - -
58d64efe by Andreas Klebinger at 2023-04-11T11:55:11+05:30
Only gc sparks locally when we can ensure marking is done.

When performing GC without work stealing there was no guarantee that
spark pruning was happening after marking of the sparks. This could
cause us to GC live sparks under certain circumstances.

Fixes #22528.

(cherry picked from commit a1491c8791c57a64d94bc08d639d585815c8d4e2)

- - - - -


30 changed files:

- compiler/GHC/Core.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Utils.hs
- rts/Capability.c
- rts/Capability.h
- rts/Messages.h
- rts/PrimOps.cmm
- rts/Printer.c
- rts/ProfHeap.c
- rts/ProfilerReport.c
- rts/ProfilerReportJson.c
- rts/Profiling.c
- rts/Proftimer.c
- rts/RetainerProfile.c
- rts/RtsAPI.c
- rts/RtsStartup.c
- rts/RtsUtils.c
- rts/RtsUtils.h
- rts/SMPClosureOps.h
- rts/STM.c
- rts/Schedule.c
- rts/Sparks.c
- rts/Stats.c
- rts/Task.c
- rts/Threads.c
- rts/TraverseHeap.c


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/aad62f1f11679d875705a0d9b86fbc9552e336cc...58d64efeeef6ae61cb7a7f33e0eafb583e1c021a

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/aad62f1f11679d875705a0d9b86fbc9552e336cc...58d64efeeef6ae61cb7a7f33e0eafb583e1c021a
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/20230411/5b336880/attachment-0001.html>

More information about the ghc-commits mailing list