[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 8 commits: Fix kind inference for data types. Again.

Tue Dec 8 21:03:22 UTC 2020

 Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC

Commits:
62ed6957 by Simon Peyton Jones at 2020-12-08T15:31:41-05:00
Fix kind inference for data types. Again.

This patch fixes several aspects of kind inference for data type
declarations, especially data /instance/ declarations

Specifically

1. In kcConDecls/kcConDecl make it clear that the tc_res_kind argument
   is only used in the H98 case; and in that case there is no result
   kind signature; and hence no need for the disgusting splitPiTys in
   kcConDecls (now thankfully gone).

   The GADT case is a bit different to before, and much nicer.
   This is what fixes #18891.

   See Note [kcConDecls: kind-checking data type decls]

2. Do not look at the constructor decls of a data/newtype instance
   in tcDataFamInstanceHeader. See GHC.Tc.TyCl.Instance
   Note [Kind inference for data family instances].  This was a
   new realisation that arose when doing (1)

   This causes a few knock-on effects in the tests suite, because
   we require more information than before in the instance /header/.

   New user-manual material about this in "Kind inference in data type
   declarations" and "Kind inference for data/newtype instance
   declarations".

3. Minor improvement in kcTyClDecl, combining GADT and H98 cases

4. Fix #14111 and #8707 by allowing the header of a data instance
   to affect kind inferece for the the data constructor signatures;
   as described at length in Note [GADT return types] in GHC.Tc.TyCl

   This led to a modest refactoring of the arguments (and argument
   order) of tcConDecl/tcConDecls.

5. Fix #19000 by inverting the sense of the test in new_locs
   in GHC.Tc.Solver.Canonical.canDecomposableTyConAppOK.

- - - - -
0abe3ddf by Adam Sandberg Ericsson at 2020-12-08T15:32:19-05:00
hadrian: build the _l and _thr_l rts flavours in the develN flavours

The ghc binary requires the eventlog rts since
fc644b1a643128041cfec25db84e417851e28bab

- - - - -
056c1c56 by Andreas Klebinger at 2020-12-08T16:03:14-05:00
CodeGen: Make folds User/DefinerOfRegs INLINEABLE.

Reduces allocation for the test case I was looking at by about 1.2%.
Mostly from avoiding allocation of some folding functions which turn
into let-no-escape bindings which just reuse their environment instead.

We also force inlining in a few key places in CmmSink which helps a bit
more.

- - - - -
f94a3141 by Andreas Klebinger at 2020-12-08T16:03:14-05:00
CmmSink: Force inlining of foldRegsDefd

Helps avoid allocating the folding function. Improves
perf for T3294 by about 1%.

- - - - -
d70e6142 by Andreas Klebinger at 2020-12-08T16:03:14-05:00
Cmm: Make a few types and utility function slightly stricter.

About 0.6% reduction in allocations for the code I was looking at.

Not a huge difference but no need to throw away performance.

- - - - -
c37de209 by Andreas Klebinger at 2020-12-08T16:03:14-05:00
Cmm.Sink: Optimize retaining of assignments, live sets.

Sinking requires us to track live local regs after each
cmm statement. We used to do this via "Set LocalReg".

However we can replace this with a solution based on IntSet
which is overall more efficient without losing much. The thing
we lose is width of the variables, which isn't used by the sinking
pass anyway.

I also reworked how we keep assignments to regs mentioned in
skipped assignments. I put the details into
Note [Keeping assignemnts mentioned in skipped RHSs].

The gist of it is instead of keeping track of it via the use count
which is a `IntMap Int` we now use the live regs set (IntSet) which
is quite a bit faster.

I think it also matches the semantics a lot better. The skipped
(not discarded) assignment does in fact keep the regs on it's rhs
alive so keeping track of this in the live set seems like the clearer
solution as well.

Improves allocations for T3294 by yet another 1%.

- - - - -
df97ab17 by Andreas Klebinger at 2020-12-08T16:03:14-05:00
GHC.Cmm.Opt: Be stricter in results.

Optimization either returns Nothing if nothing is to be done or
`Just <cmmExpr>` otherwise. There is no point in being lazy in
`cmmExpr`. We usually inspect this element so the thunk gets forced
not long after.

We might eliminate it as dead code once in a blue moon but that's
not a case worth optimizing for.

Overall the impact of this is rather low. As Cmm.Opt doesn't allocate
much (compared to the rest of GHC) to begin with.

- - - - -
ed940d47 by Andreas Klebinger at 2020-12-08T16:03:14-05:00
Bump time submodule.

This should fix #19002.

- - - - -

30 changed files:

- compiler/GHC/Cmm/Expr.hs
- + compiler/GHC/Cmm/LRegSet.hs
- compiler/GHC/Cmm/Liveness.hs
- compiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Opt.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Solver/Canonical.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/TyCl/Instance.hs
- compiler/GHC/Utils/Outputable.hs
- compiler/ghc.cabal.in
- docs/users_guide/9.2.1-notes.rst
- docs/users_guide/exts/poly_kinds.rst
- hadrian/src/Settings/Flavours/Development.hs
- libraries/time
- testsuite/tests/dependent/should_fail/T13780a.stderr
- testsuite/tests/deriving/should_compile/T11416.hs
- testsuite/tests/deriving/should_compile/T9359.hs
- + testsuite/tests/gadt/SynDataRec.hs
- testsuite/tests/gadt/all.T
- + testsuite/tests/indexed-types/should_compile/T14111.hs
- + testsuite/tests/indexed-types/should_compile/T8707.hs
- testsuite/tests/indexed-types/should_compile/all.T
- testsuite/tests/indexed-types/should_fail/T8368.stderr
- testsuite/tests/indexed-types/should_fail/T8368a.stderr
- testsuite/tests/patsyn/should_fail/T15685.stderr
- testsuite/tests/polykinds/T13659.stderr

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5cb804dfbb39f214f8bfe4fbc0c1380825b3d912...ed940d47e8a4abdeb0ce54fcd8db46274713a248

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5cb804dfbb39f214f8bfe4fbc0c1380825b3d912...ed940d47e8a4abdeb0ce54fcd8db46274713a248
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/20201208/6da52da3/attachment-0001.html>