[Git][ghc/ghc][ghc-9.2] 19 commits: Revert "Fix combination of ArityType in andArityType"
Zubin (@wz1000)
gitlab at gitlab.haskell.org
Thu Nov 3 20:35:45 UTC 2022
Zubin pushed to branch ghc-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.
- - - - -
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/a54827e0b48af33fa9cfde6ad131c6751c2fe321...c35d3f805da2f70cf76fca1d76d984c7a428f42b
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a54827e0b48af33fa9cfde6ad131c6751c2fe321...c35d3f805da2f70cf76fca1d76d984c7a428f42b
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/20221103/37f78471/attachment-0001.html>
More information about the ghc-commits
mailing list