<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<h3>
Simon Peyton Jones pushed to branch wip/T17775
at <a href="https://gitlab.haskell.org/ghc/ghc">Glasgow Haskell Compiler / GHC</a>
</h3>
<h4>
Commits:
</h4>
<ul>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/dcfe29c8520244764146c7a5f336be1f9700db6c">dcfe29c8</a></strong>
<div>
<span>by Ömer Sinan Ağacan</span>
<i>at 2020-04-06T13:16:08-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Don't override proc CafInfos in ticky builds
Fixes #17947
When we have a ticky label for a proc, IdLabels for the ticky counter
and proc entry share the same Name. This caused overriding proc CafInfos
with the ticky CafInfos (i.e. NoCafRefs) during SRT analysis.
We now ignore the ticky labels when building SRTMaps. This makes sense
because:
- When building the current module they don't need to be in SRTMaps as
they're initialized as non-CAFFY (see mkRednCountsLabel), so they
don't take part in the dependency analysis and they're never added to
SRTs.
(Reminder: a "dependency" in the SRT analysis is a CAFFY dependency,
non-CAFFY uses are not considered as dependencies for the algorithm)
- They don't appear in the interfaces as they're not exported, so it
doesn't matter for cross-module concerns whether they're in the SRTMap
or not.
See also the new Note [Ticky labels in SRT analysis].
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/cec2c71fe91c88649628c6e83416533b816b86a5">cec2c71f</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-06T13:16:44-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Fix an tricky specialiser loop
Issue #17151 was a very tricky example of a bug in which the
specialiser accidentally constructs a recurive dictionary,
so that everything turns into bottom.
I have fixed variants of this bug at least twice before:
see Note [Avoiding loops]. It was a bit of a struggle
to isolate the problem, greatly aided by the work that
Alexey Kuleshevich did in distilling a test case.
Once I'd understood the problem, it was not difficult to fix,
though it did lead me a bit of refactoring in specImports.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/e850d14ffbeea39ad386b1e888cd97375758d6d6">e850d14f</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-06T13:16:44-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Refactoring only
This refactors DictBinds into a data type rather than a pair.
No change in behaviour, just better code
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/f38e8d61f066c3064c600c352eebcd87f28d989a">f38e8d61</a></strong>
<div>
<span>by Daniel Gröber</span>
<i>at 2020-04-07T02:00:05-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">rts: ProfHeap: Fix memory leak when not compiled with profiling
If we're doing heap profiling on an unprofiled executable we keep
allocating new space in initEra via nextEra on each profiler run but we
don't have a corresponding freeEra call.
We do free the last era in endHeapProfiling but previous eras will have
been overwritten by initEra and will never get free()ed.
Metric Decrease:
space_leak_001
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/bcd668593e1c9e00c5d9c72960b4833dd526cb9a">bcd66859</a></strong>
<div>
<span>by Sebastian Graf</span>
<i>at 2020-04-07T02:00:41-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Re-export GHC.Magic.noinline from base
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/3d2991f8b4c1b686323b2c9452ce845a60b8d94c">3d2991f8</a></strong>
<div>
<span>by Ben Gamari</span>
<i>at 2020-04-07T18:36:09-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">simplifier: Kill off ufKeenessFactor
We used to have another factor, ufKeenessFactor, which would scale the
discounts before they were subtracted from the size. This was justified
with the following comment:
-- We multiple the raw discounts (args_discount and result_discount)
-- ty opt_UnfoldingKeenessFactor because the former have to do with
-- *size* whereas the discounts imply that there's some extra
-- *efficiency* to be gained (e.g. beta reductions, case reductions)
-- by inlining.
However, this is highly suspect since it means that we subtract a
*scaled* size from an absolute size, resulting in crazy (e.g. negative)
scores in some cases (#15304). We consequently killed off
ufKeenessFactor and bumped up the ufUseThreshold to compensate.
Adjustment of unfolding use threshold
=====================================
Since this removes a discount from our inlining heuristic, I revisited our
default choice of -funfolding-use-threshold to minimize the change in
overall inlining behavior. Specifically, I measured runtime allocations
and executable size of nofib and the testsuite performance tests built
using compilers (and core libraries) built with several values of
-funfolding-use-threshold.
This comes as a result of a quantitative comparison of testsuite
performance and code size as a function of ufUseThreshold, comparing
GHC trees using values of 50, 60, 70, 80, 90, and 100. The test set
consisted of nofib and the testsuite performance tests.
A full summary of these measurements are found in the description of
!2608
Comparing executable sizes (relative to the base commit) across all
nofib tests, we see that sizes are similar to the baseline:
gmean min max median
thresh
50 -6.36% -7.04% -4.82% -6.46%
60 -5.04% -5.97% -3.83% -5.11%
70 -2.90% -3.84% -2.31% -2.92%
80 -0.75% -2.16% -0.42% -0.73%
90 +0.24% -0.41% +0.55% +0.26%
100 +1.36% +0.80% +1.64% +1.37%
baseline +0.00% +0.00% +0.00% +0.00%
Likewise, looking at runtime allocations we see that 80 gives slightly
better optimisation than the baseline:
gmean min max median
thresh
50 +0.16% -0.16% +4.43% +0.00%
60 +0.09% -0.00% +3.10% +0.00%
70 +0.04% -0.09% +2.29% +0.00%
80 +0.02% -1.17% +2.29% +0.00%
90 -0.02% -2.59% +1.86% +0.00%
100 +0.00% -2.59% +7.51% -0.00%
baseline +0.00% +0.00% +0.00% +0.00%
Finally, I had to add a NOINLINE in T4306 to ensure that `upd` is
worker-wrappered as the test expects. This makes me wonder whether the
inlining heuristic is now too liberal as `upd` is quite a large
function. The same measure was taken in T12600.
Wall clock time compiling Cabal with -O0
thresh 50 60 70 80 90 100 baseline
build-Cabal 93.88 89.58 92.59 90.09 100.26 94.81 89.13
Also, this change happens to avoid the spurious test output in
`plugin-recomp-change` and `plugin-recomp-change-prof` (see #17308).
Metric Decrease:
hie002
T12234
T13035
T13719
T14683
T4801
T5631
T5642
T9020
T9872d
T9961
Metric Increase:
T12150
T12425
T13701
T14697
T15426
T1969
T3064
T5837
T6048
T9203
T9872a
T9872b
T9872c
T9872d
haddock.Cabal
haddock.base
haddock.compiler
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/255418da5d264fb2758bc70925adb2094f34adc3">255418da</a></strong>
<div>
<span>by Sylvain Henry</span>
<i>at 2020-04-07T18:36:49-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Modules: type-checker (#13009)
Update Haddock submodule
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/04b6cf947ea065a210a216cc91f918cc1660d430">04b6cf94</a></strong>
<div>
<span>by Ryan Scott</span>
<i>at 2020-04-07T19:43:20-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Make NoExtCon fields strict
This changes every unused TTG extension constructor to be strict in
its field so that the pattern-match coverage checker is smart enough
any such constructors are unreachable in pattern matches. This lets
us remove nearly every use of `noExtCon` in the GHC API. The only
ones we cannot remove are ones underneath uses of `ghcPass`, but that
is only because GHC 8.8's and 8.10's coverage checkers weren't smart
enough to perform this kind of reasoning. GHC HEAD's coverage
checker, on the other hand, _is_ smart enough, so we guard these uses
of `noExtCon` with CPP for now.
Bumps the `haddock` submodule.
Fixes #17992.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/7802fa17a9a1a0f02fbf95170c13d7a9711a681e">7802fa17</a></strong>
<div>
<span>by Ryan Scott</span>
<i>at 2020-04-08T16:43:44-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Handle promoted data constructors in typeToLHsType correctly
Instead of using `nlHsTyVar`, which hardcodes `NotPromoted`, have
`typeToLHsType` pick between `Promoted` and `NotPromoted` by checking
if a type constructor is promoted using `isPromotedDataCon`.
Fixes #18020.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/14132e971ff0ad62b95d4663b669fa684ef94a1e">14132e97</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-09T16:09:04+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Simplify subsumption
This patch implements GHC Proposal 287: Simplify subsumption
and ticket #17775.
The highlights are:
* No deeplyInstantiate or deeplySkolemise
* No tcSubTypeDS
Everything else is a knock-on effect.
I did a bit of renaming to make things consistent
* tcPolyExpr becomes tcCheckPolyExpr
ditto tcPolyExprNC
* Add new function
tcCheckMonoExpr e ty = tcMon0Expr expr (mkCheckExpType ty)
and use it
This all comopiles, but needs some eta-expansion in haskeline, and
doubtless other packages.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/7feb5df96377e72c5ead721169f893c93688cbba">7feb5df9</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-09T16:13:14+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Further refactoring and simplification
Reviewed the main changes with Richard
I had to do eta-expansion in a number of tests:
T10283
T10390
T14488
T1634
T4284
T9569a
T9834
tc145
tc160
tc208
tc210
twins
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/548d8f22bbd40b7227adf3226c07c76d7f22be7b">548d8f22</a></strong>
<div>
<span>by Ben Gamari</span>
<i>at 2020-04-09T16:13:14+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Bump haskeline submodule
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/e9c0333b9ddd17c4db2302073504201d3ec8183d">e9c0333b</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-09T16:13:18+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Delete commented-out code
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/4cbf8fc544e1054a1451b7ae580fb016d7e147f8">4cbf8fc5</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-09T16:13:20+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Fix (breaking) typo
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/9a92286cd14892a953a17fac97cc256e379c092b">9a92286c</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-09T16:13:22+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Improve decomposition for FunTys
This just improves error messages, avoiding
Couldn't match type ‘Char’ with ‘Show a -> Char’
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/c61810f6651ef96e6c1d2a6825dbc02113f41969">c61810f6</a></strong>
<div>
<span>by Ryan Scott</span>
<i>at 2020-04-09T16:13:22+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Bump Cabal submodule
As well as some miscellaneous fixes needed to make GHC itself
compile under simplified subsumption.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/279b173a8dfa3ad0d4f6967e8cc25ecc81c0ccdf">279b173a</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-09T16:15:51+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Wibbles
* Get expected/actual the right way round
* Relevant-bindings fixes
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/474331ace3eed36e398b76ce08c958fff3a9051d">474331ac</a></strong>
<div>
<span>by Simon Peyton Jones</span>
<i>at 2020-04-13T10:11:04+01:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">A lot more wibbles
* Made String wired-in, so that
"foo" :: String rather than
"foo" :: [Char]
* isTauTy: account for =>
* Bring dicts into scope when desugaring HsWrappers:
addTyCsDs and hsWrapDictBinders
* Improve reporting for occurs checks where
skolems are involved e.g. 10715b, mc19, tcfail193, T13674,
T4272, T3169, T7758, 7148
Payload is in the first case of mkTyVarEqErr
* solveLocalEqualitesX: fail faster.
we want to fail fast in T11142
Another example: T15629
And keep all equalities in dropMisleading. This gives better
reporting in T12593 for example.
* Move checkDataKindSig after the solveEqualities and zonk,
obviously!
* Move ic_telescope into ForAllSkol; a nice win.
* Pretty-printing AbsBinds
We are now very close to green
</pre>
</li>
</ul>
<h4>30 changed files:</h4>
<ul>
<li class="file-stats">
<a href="#abe895765c4ce08c5dfbc95e5e3c5db67ff92ded">
CODEOWNERS
</a>
</li>
<li class="file-stats">
<a href="#d0d96a6d03668aeab20ebe05e2c4ccb798c7e64c">
compiler/GHC.hs
</a>
</li>
<li class="file-stats">
<a href="#db697f6aea9f93f1583f1d5c62d25570a1e07f73">
compiler/GHC/Cmm/CLabel.hs
</a>
</li>
<li class="file-stats">
<a href="#56e23d78cfece2c83f03ed9b9a8ce9b20be26462">
compiler/GHC/Cmm/Expr.hs
</a>
</li>
<li class="file-stats">
<a href="#2d3721ad8de95e1144493ca545db846672cb109f">
compiler/GHC/Cmm/Info/Build.hs
</a>
</li>
<li class="file-stats">
<a href="#90378e83c3a00a78bc0b3c01da111e0a787de451">
compiler/GHC/Cmm/Node.hs
</a>
</li>
<li class="file-stats">
<a href="#182d6a315e784018aa9c8b2ad736036b97bd5d48">
compiler/GHC/Core.hs
</a>
</li>
<li class="file-stats">
<a href="#8b1482a65a3092c268b853a00aa18286427d1dec">
compiler/GHC/Core/Arity.hs
</a>
</li>
<li class="file-stats">
<a href="#e39f2416dd3b2af571ddd26dcca3476a55810c41">
compiler/GHC/Core/Class.hs
</a>
</li>
<li class="file-stats">
<a href="#783e5dae6e86931f06700fc088fb7d48c8a07386">
compiler/GHC/Core/Coercion.hs
</a>
</li>
<li class="file-stats">
<a href="#f10ed7a2470454dfdd8691a08beba67d8b78ee70">
compiler/GHC/Core/Coercion/Axiom.hs
</a>
</li>
<li class="file-stats">
<a href="#975dc08a8e7942b32d621f617d5a9c1b668601dd">
compiler/GHC/Core/Coercion/Opt.hs
</a>
</li>
<li class="file-stats">
<a href="#91648438362e5a35363d2bb7abb04016dedd7d7e">
compiler/GHC/Core/FamInstEnv.hs
</a>
</li>
<li class="file-stats">
<a href="#5596bb0f228bd2a308c4391df97375ae879430a8">
compiler/GHC/Core/InstEnv.hs
</a>
</li>
<li class="file-stats">
<a href="#36a42448a83a9d1f6df8475f03ead2eed199dd8e">
compiler/GHC/Core/Lint.hs
</a>
</li>
<li class="file-stats">
<a href="#e5041b26fef1c846489ee5e1c883bc3d52cc775b">
compiler/GHC/Core/Op/CSE.hs
</a>
</li>
<li class="file-stats">
<a href="#9e2ce77a946950b2d19d75c55f671c048a5645bd">
compiler/GHC/Core/Op/OccurAnal.hs
</a>
</li>
<li class="file-stats">
<a href="#e3fe84599ec044fc7aacb062dada32b067732fc8">
compiler/GHC/Core/Op/Simplify.hs
</a>
</li>
<li class="file-stats">
<a href="#d52bc1e90d7432064a2998de2a2751b6fecb7680">
compiler/GHC/Core/Op/Specialise.hs
</a>
</li>
<li class="file-stats">
<a href="#5e5f8dbd247535be3f94c4bac0005587d000dba0">
compiler/GHC/Core/PatSyn.hs
</a>
</li>
<li class="file-stats">
<a href="#0ca1508e5b0cedec2f19fe10e414597184209573">
compiler/GHC/Core/Predicate.hs
</a>
</li>
<li class="file-stats">
<a href="#d01de95d8c71d4dec6a9a59146186e29a5b3fd38">
compiler/GHC/Core/Rules.hs
</a>
</li>
<li class="file-stats">
<a href="#039e8f5676356ef05c90af828aae48aac7296e47">
compiler/GHC/Core/TyCo/FVs.hs
</a>
</li>
<li class="file-stats">
<a href="#379343fa560df0c7451aa5a1dd4f074dd37924d0">
compiler/GHC/Core/TyCo/Ppr.hs
</a>
</li>
<li class="file-stats">
<a href="#578c7c3857d66d963736ff6742f3433a0e8d01b7">
compiler/GHC/Core/TyCo/Rep.hs
</a>
</li>
<li class="file-stats">
<a href="#4aad0050db1a8a20db8bbca149111de99cb299c9">
compiler/GHC/Core/TyCon.hs
</a>
</li>
<li class="file-stats">
<a href="#84c9d3ba34173297e7d7747e02caa2e004b164fc">
compiler/GHC/Core/Type.hs
</a>
</li>
<li class="file-stats">
<a href="#2811a7297b8aa206197ac1f5dabd0818e3c7ec5a">
compiler/GHC/Core/Unfold.hs
</a>
</li>
<li class="file-stats">
<a href="#89a2e0e1a3095c7a42b10f2819049908908080e8">
compiler/GHC/Core/Unify.hs
</a>
</li>
<li class="file-stats">
<a href="#a5d27de4e3111a69f69902c65ecf7b3379f7c49a">
compiler/GHC/CoreToStg/Prep.hs
</a>
</li>
</ul>
<h5>The diff was not included because it is too large.</h5>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777;">
—
<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/compare/bd8eda7c22e8ccf88c2bf30de3edb69ba5519e2c...474331ace3eed36e398b76ce08c958fff3a9051d">View it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.haskell.org.
If you'd like to receive fewer emails, you can
adjust your notification settings.
</p>
</div>
</body>
</html>