[Git][ghc/ghc][wip/T22264-9.2] 26 commits: Revert "Fix combination of ArityType in andArityType"

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Tue Dec 6 02:55:27 UTC 2022



Ben Gamari pushed to branch wip/T22264-9.2 at Glasgow Haskell Compiler / GHC


Commits:
8b839c33 by Zubin Duggal at 2022-10-11T11:12:07+01:00
Revert "Fix combination of ArityType in andArityType"

This reverts commit 74ef2853464255a86d88fda619eb68b08b52e689.

- - - - -
c45387ce by Simon Peyton Jones at 2022-10-26T15:39:08+05:30
Fix arityType: -fpedantic-bottoms, join points, etc

This MR fixes #21694 and #21755

* For #21694 the underlying problem was that we were calling arityType
  on an expression that had free join points.  This is a Bad Bad Idea.
  See Note [No free join points in arityType].

* I also made andArityType work correctly with -fpedantic-bottoms;
  see Note [Combining case branches: andWithTail].

* I realised that, now we have ae_sigs giving the ArityType for
  let-bound Ids, we don't need the (pre-dating) special code in
  arityType for join points. But instead we need to extend the env for
  Rec bindings, which weren't doing before.  More uniform now.  See
  Note [arityType for let-bindings].

  This meant we could get rid of ae_joins, and in fact get rid of
  EtaExpandArity altogether.  Simpler.

  And finally, it was the strange treatment of join-point Ids (involving
  a fake ABot type) that led to a serious bug: #21755.  Fixed by this
  refactoring

* Rewrote Note [Combining case branches: optimistic one-shot-ness]

Compile time improves slightly on average:

Metrics: compile_time/bytes allocated
---------------------------------------------------------------------------------------
CoOpt_Read(normal) ghc/alloc    803,788,056    747,832,680  -7.1% GOOD
    T18223(normal) ghc/alloc    928,207,320    959,424,016  +3.1%  BAD
         geo. mean                                          -0.3%
         minimum                                            -7.1%
         maximum                                            +3.1%

On Windows it's a bit better: geo mean is -0.6%, and three more
benchmarks trip their compile-time bytes-allocated threshold (they
were all close on the other build):

   T18698b(normal) ghc/alloc    235,619,776    233,219,008  -1.0% GOOD
     T6048(optasm) ghc/alloc    112,208,192    109,704,936  -2.2% GOOD
    T18140(normal) ghc/alloc     85,064,192     83,168,360  -2.2% GOOD

I had a quick look at T18223 but it is knee deep in coercions and
the size of everything looks similar before and after.  I decided
to accept that 3.4% increase in exchange for goodness elsewhere.

Metric Decrease:
    CoOpt_Read
    T18140
    T18698b
    T6048

Metric Increase:
    T18223

- - - - -
8a38c548 by Ben Gamari at 2022-10-26T15:39:08+05:30
rts: Don't clear cards of zero-length arrays

Fix #21962, where attempting to clear the card table of a zero-length
array resulted in an integer underflow.

- - - - -
17552468 by Cheng Shao at 2022-10-26T15:39:08+05:30
rts: fix missing dirty_MVAR argument in stg_writeIOPortzh

(cherry picked from commit ee471dfb8a4a4bb5131a5baa61d1d0d22c933d5f)

- - - - -
4d047b3c by Matthew Pickering at 2022-10-26T15:39:08+05:30
Don't include BufPos in interface files

Ticket #22162 pointed out that the build directory was leaking into the
ABI hash of a module because the BufPos depended on the location of the
build tree.

BufPos is only used in GHC.Parser.PostProcess.Haddock, and the
information doesn't need to be propagated outside the context of a
module.

Fixes #22162

(cherry picked from commit 7f0decd5063a853fc8f38a8944b2c91995cd5e48)

- - - - -
9e254001 by Ben Gamari at 2022-10-26T15:39:08+05:30
ncg/aarch64: Fix sub-word sign extension yet again

In adc7f108141a973b6dcb02a7836eed65d61230e8 we fixed a number of issues
to do with sign extension in the AArch64 NCG found by ghc/test-primops>.
However, this patch made a critical error, assuming that getSomeReg
would allocate a fresh register for the result of its evaluation.
However, this is not the case as `getSomeReg (CmmReg r) == r`.
Consequently, any mutation of the register returned by `getSomeReg` may
have unwanted side-effects on other expressions also mentioning `r`. In
the fix listed above, this manifested as the registers containing the
operands of binary arithmetic operations being incorrectly
sign-extended. This resulted in #22282.

Sadly, the rather simple structure of the tests generated
by `test-primops` meant that this particular case was not exercised.
Even more surprisingly, none of our testsuite caught this case.

Here we fix this by ensuring that intermediate sign extension is
performed in a fresh register.

Fixes #22282.

(cherry picked from commit 62a550010ed94e1969c96150f2781854a0802766)

- - - - -
74e329d2 by Ben Gamari at 2022-10-26T15:39:08+05:30
testsuite: Add test for #22282

This will complement mpickering's more general port of foundation's
numerical testsuite, providing a test for the specific case found
in #22282.

(cherry picked from commit 8eff62a43cebbb21f00aeea138bcc343d8ac8f34)

- - - - -
064371d3 by Douglas Wilson at 2022-10-26T15:39:09+05:30
testsuite: 21651 add test for closeFdWith + setNumCapabilities

This bug does not affect windows, which does not use the
base module GHC.Event.Thread.

(cherry picked from commit 76b52cf0c52ee05c20f7d1b80f5600eecab3c42a)

- - - - -
2821391a by Douglas Wilson at 2022-10-26T15:39:09+05:30
base: Fix races in IOManager (setNumCapabilities,closeFdWith)

Fix for #21651

Fixes three bugs:

- writes to eventManager should be atomic. It is accessed concurrently by ioManagerCapabilitiesChanged and closeFdWith.
- The race in closeFdWith described in the ticket.
- A race in getSystemEventManager where it accesses the 'IOArray' in
  'eventManager' before 'ioManagerCapabilitiesChanged' has written to
  'eventManager', causing an Array Index exception. The fix here is to
  'yield' and retry.

(cherry picked from commit 7589ee7241d46b393979d98d4ded17a15ee974fb)

- - - - -
7ad76d79 by Tamar Christina at 2022-10-26T15:39:09+05:30
winio: do not re-translate input when handle is uncooked

(cherry picked from commit 626652f7c172f307bd87afaee59c7f0e2825c55d)

- - - - -
63fe2ee2 by Sebastian Graf at 2022-11-03T14:21:10+05:30
Rubbish literals for all representations (#18983)

This patch cleans up the complexity around WW's `mk_absent_let` by
broadening the scope of `LitRubbish`. Rubbish literals now store the
`PrimRep` they represent and are ultimately lowered in Cmm.
This in turn allows absent literals of `VecRep` or `VoidRep`. The latter
allows absent literals for unlifted coercions, as requested in #18983.

I took the liberty to rewrite and clean up `Note [Absent fillers]` and
`Note [Rubbish values]` to account for the new implementation and to
make them more orthogonal in their description.

I didn't add a new regression test, as `T18982` already contains the
test in the ticket and its test output changes as expected.

Fixes #18983.

- - - - -
1fabaae4 by Dai at 2022-11-03T15:12:38+05:30
Add VecSlot for unboxed sums of SIMD vectors

This patch adds the missing `VecRep` case to `primRepSlot` function and
all the necessary machinery to carry this new `VecSlot` through code
generation. This allows programs involving unboxed sums of SIMD vectors
to be written and compiled.

Fixes #22187

(cherry picked from commit 5b3a992f5d166007c3c5a22f120ed08e0a27f01a)

- - - - -
9d469bff by sheaf at 2022-11-03T15:12:38+05:30
Cmm Lint: relax SIMD register assignment check

As noted in #22297, SIMD vector registers can be used
to store different kinds of values, e.g. xmm1 can be used
both to store integer and floating point values.
The Cmm type system doesn't properly account for this, so
we weaken the Cmm register assignment lint check to only
compare widths when comparing a vector type with its
allocated vector register.

(cherry picked from commit 3be48877e204fca8e5d5ab984186e0d20d81f262)

- - - - -
14e0442e by sheaf at 2022-11-03T15:12:38+05:30
Disable some SIMD tests on non-X86 architectures

(cherry picked from commit f7b7a3122185222d5059e37315991afcf319e43c)

- - - - -
45459cce by Zubin Duggal at 2022-11-03T15:12:38+05:30
Bump process to 1.6.16.0

- - - - -
5674eb8b by Zubin Duggal at 2022-11-03T15:12:38+05:30
Attemp fix for core lint failures

For an expression:

  joinrec foo = ... in expr

we compute the arityType as `foldr andArityType (arityType expr) [arityType foo]`
which is the same as `andArityType (arityType expr) (arityType foo)`. However,
this is incorrect:

  joinrec go x = ... in go 0

then the arity of go is 1 (\?. T), but the arity of the overall expression is
0 (_|_). `andArityType` however returns (\?. T) for these, which is wrong.

(cherry picked from commit 53235edd478bd4c5e29e4f254ce02559af259dd5)

- - - - -
36cfeb7c by Zubin Duggal at 2022-11-03T15:12:38+05:30
Bump base to 4.16.4.0 and add release notes

- - - - -
3588c3a9 by Zubin Duggal at 2022-11-03T15:12:38+05:30
Fix bkpcabal02

- - - - -
c35d3f80 by Zubin Duggal at 2022-11-03T17:15:22+05:30
Fix core lint errors to do with SIMD vector indexing in T22187_run.

This patch was originally from 6d7d91817795d7ee7f45557411368a1738daa488,
but all the changes in that commit can't make it because we don't want to
change the interface of primops in a backport.

- - - - -
784324bc by Zubin Duggal at 2022-11-04T15:39:38+05:30
Add notes for 9.2.5

- - - - -
74ca6191 by normalcoder at 2022-11-07T00:06:37+05:30
ncg/aarch64: Don't use x18 register on AArch64/Darwin

Apple's ABI documentation [1] says: "The platforms reserve register x18.
Don’t use this register." While this wasn't problematic in previous
Darwin releases, macOS 13 appears to start zeroing this register
periodically. See #21964.

[1] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms

(cherry picked from commit 67575f2004340564d6e52af055ed6fb43d3f9711)

- - - - -
98d62a98 by Ben Gamari at 2022-12-05T21:43:13-05:00
nonmoving: Don't push empty arrays to update remembered set

Previously the write barrier of resizeSmallArray# incorrectly handled
resizing of zero-sized arrays, pushing an invalid pointer to the update
remembered set.

Likely fixes the cause of #22264.

(cherry picked from commit f8988a9c53ae73ff5b9c6008f467a7171e99c61f)

- - - - -
c0a9329b by Ben Gamari at 2022-12-05T21:46:58-05:00
nonmoving: Fix handling of weak pointers

This fixes an interaction between aging and weak pointer handling which
prevented the finalization of some weak pointers. In particular, weak
pointers could have their keys incorrectly marked by the preparatory
collector, preventing their finalization by the subsequent concurrent
collection.

While in the area, we also significantly improve the assertions
regarding weak pointers.

Fixes #22327.

(cherry picked from commit cab678fc11d0a3f28fbf2210c4c0bb04eb52997d)

- - - - -
e6b83196 by Ben Gamari at 2022-12-05T21:47:21-05:00
nonmoving: Handle new closures in nonmovingIsNowAlive

(cherry picked from commit 36ca160d0f199a688cf5fbc91d4bb92d2d4ea14e)

- - - - -
62031282 by Ben Gamari at 2022-12-05T21:48:03-05:00
nonmoving: Don't clobber update rem sets of old capabilities

Previously `storageAddCapabilities` (called by `setNumCapabilities`) would
clobber the update remembered sets of existing capabilities when
increasing the capability count. Fix this by only initializing the
update remembered sets of the newly-created capabilities.

(cherry picked from commit 8b64aff0fa978c762dfae8df235dd2b2a340656a)

- - - - -
c6f17f12 by Ben Gamari at 2022-12-05T21:49:31-05:00
nonmoving: Add missing write barriers in selector optimisation

This fixes the selector optimisation, adding a few write barriers which
are necessary for soundness.

(cherry picked from commit dde67d6e32ecff0e400f98213d42ae790babac09)

- - - - -


30 changed files:

- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Cmm/LayoutStack.hs
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Stg/Unarise.hs
- compiler/GHC/StgToCmm/ArgRep.hs
- compiler/GHC/StgToCmm/Env.hs
- compiler/GHC/StgToCmm/Expr.hs
- + compiler/GHC/StgToCmm/Expr.hs-boot
- compiler/GHC/StgToCmm/Foreign.hs
- compiler/GHC/StgToCmm/Heap.hs
- compiler/GHC/StgToCmm/Layout.hs
- + compiler/GHC/StgToCmm/Lit.hs
- compiler/GHC/StgToCmm/Monad.hs
- compiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/StgToCmm/Prof.hs
- compiler/GHC/StgToCmm/Ticky.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4b09bd5bdebe32ce864286f19d6c78f7ebc6faf1...c6f17f1218301dc7aed2a3d29f071353ee16fb89

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4b09bd5bdebe32ce864286f19d6c78f7ebc6faf1...c6f17f1218301dc7aed2a3d29f071353ee16fb89
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/20221205/e5eebffc/attachment-0001.html>


More information about the ghc-commits mailing list