[Git][ghc/ghc][wip/mp-9.2.5-backports] 14 commits: Fix arityType: -fpedantic-bottoms, join points, etc

Zubin (@wz1000) gitlab at gitlab.haskell.org
Wed Oct 26 10:09:19 UTC 2022



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


Commits:
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)

- - - - -
cec34e3e by Dai at 2022-10-26T15:39:09+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)

- - - - -
006ed7f0 by sheaf at 2022-10-26T15:39:09+05:30
Remove SIMD conversions

This patch makes it so that packing/unpacking SIMD
vectors always uses the right sized types, e.g.
unpacking a Word16X4# will give a tuple of Word16#s.

As a result, we can get rid of the conversion instructions
that were previously required.

Fixes #22296

(cherry picked from commit 6d7d91817795d7ee7f45557411368a1738daa488)

- - - - -
499c1fda by sheaf at 2022-10-26T15:39:09+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)

- - - - -
5c32935c by sheaf at 2022-10-26T15:39:09+05:30
Disable some SIMD tests on non-X86 architectures

(cherry picked from commit f7b7a3122185222d5059e37315991afcf319e43c)

- - - - -
f52a6897 by Zubin Duggal at 2022-10-26T15:39:09+05:30
Bump process to 1.6.16.0

- - - - -


30 changed files:

- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Stg/Unarise.hs
- compiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/Types/RepType.hs
- compiler/GHC/Types/SrcLoc.hs
- compiler/GHC/Utils/Binary.hs
- libraries/base/GHC/Event/Thread.hs
- libraries/base/GHC/IO/Windows/Handle.hsc
- libraries/process
- rts/PrimOps.cmm
- + testsuite/tests/arityanal/should_compile/T21755.hs
- + testsuite/tests/arityanal/should_compile/T21755.stderr
- testsuite/tests/arityanal/should_compile/all.T
- + testsuite/tests/array/should_run/T21962.hs
- testsuite/tests/array/should_run/all.T
- + testsuite/tests/codeGen/should_run/T22296.hs
- + testsuite/tests/codeGen/should_run/T22296.stdout
- testsuite/tests/codeGen/should_run/all.T
- + testsuite/tests/concurrent/T2317/T21694a.hs
- + testsuite/tests/concurrent/T2317/T21694a.stderr


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/71af81f834fc02afedc86d61bde66ab79972bf5b...f52a689761670ef7420cc0a0e318259806b46da4

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/71af81f834fc02afedc86d61bde66ab79972bf5b...f52a689761670ef7420cc0a0e318259806b46da4
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/20221026/e0bbc912/attachment-0001.html>


More information about the ghc-commits mailing list