[Git][ghc/ghc][wip/T21851-rule-win] 3 commits: Demand: Clear distinction between Call SubDmd and eval Dmd (#21717)
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Wed Sep 28 10:42:58 UTC 2022
Simon Peyton Jones pushed to branch wip/T21851-rule-win at Glasgow Haskell Compiler / GHC
Commits:
aeafdba5 by Sebastian Graf at 2022-09-27T15:14:54+02:00
Demand: Clear distinction between Call SubDmd and eval Dmd (#21717)
In #21717 we saw a reportedly unsound strictness signature due to an unsound
definition of plusSubDmd on Calls. This patch contains a description and the fix
to the unsoundness as outlined in `Note [Call SubDemand vs. evaluation Demand]`.
This fix means we also get rid of the special handling of `-fpedantic-bottoms`
in eta-reduction. Thanks to less strict and actually sound strictness results,
we will no longer eta-reduce the problematic cases in the first place, even
without `-fpedantic-bottoms`.
So fixing the unsoundness also makes our eta-reduction code simpler with less
hacks to explain. But there is another, more unfortunate side-effect:
We *unfix* #21085, but fortunately we have a new fix ready:
See `Note [mkCall and plusSubDmd]`.
There's another change:
I decided to make `Note [SubDemand denotes at least one evaluation]` a lot
simpler by using `plusSubDmd` (instead of `lubPlusSubDmd`) even if both argument
demands are lazy. That leads to less precise results, but in turn rids ourselves
from the need for 4 different `OpMode`s and the complication of
`Note [Manual specialisation of lub*Dmd/plus*Dmd]`. The result is simpler code
that is in line with the paper draft on Demand Analysis.
I left the abandoned idea in `Note [Unrealised opportunity in plusDmd]` for
posterity. The fallout in terms of regressions is negligible, as the testsuite
and NoFib shows.
```
Program Allocs Instrs
--------------------------------------------------------------------------------
hidden +0.2% -0.2%
linear -0.0% -0.7%
--------------------------------------------------------------------------------
Min -0.0% -0.7%
Max +0.2% +0.0%
Geometric Mean +0.0% -0.0%
```
Fixes #21717.
- - - - -
9b1595c8 by Ross Paterson at 2022-09-27T14:12:01-04:00
implement proposal 106 (Define Kinds Without Promotion) (fixes #6024)
includes corresponding changes to haddock submodule
- - - - -
c20396fa by Simon Peyton Jones at 2022-09-28T11:45:01+01:00
Make rewrite rules "win" over inlining
If a rewrite rule and a rewrite rule compete in the simplifier, this
patch makes sure that the rewrite rule "win". That is, in general
a bit fragile, but it's a huge help when making specialisation work
reliably, as #21851 and #22097 showed.
The change is fairly straightforwad, and documented in
Note [Rewrite rules and inlining]
in GHC.Core.Opt.Simplify.Iteration.
Compile-times change quite a bit, but the trend is slightly
down
Metrics: compile_time/bytes allocated
-------------------------------------
Baseline
Test Metric value New value Change
-------------------------------------------------------------------------
LargeRecord(normal) ghc/alloc 6,084,071,354 4,566,082,536 -25.0% GOOD
T10421(normal) ghc/alloc 111,994,304 116,148,544 +3.7% BAD
T10421a(normal) ghc/alloc 79,150,034 83,423,664 +5.4%
T10547(normal) ghc/alloc 28,211,501 28,177,960 -0.1%
T12545(normal) ghc/alloc 1,633,149,272 1,614,005,512 -1.2%
T13253(normal) ghc/alloc 343,592,469 347,635,808 +1.2%
T14052(ghci) ghc/alloc 3,681,055,512 3,749,063,688 +1.8%
T15304(normal) ghc/alloc 1,295,512,578 1,277,067,608 -1.4%
T16577(normal) ghc/alloc 8,050,423,421 8,291,093,504 +3.0% BAD
T17516(normal) ghc/alloc 1,800,051,592 1,840,575,008 +2.3%
T17836(normal) ghc/alloc 829,913,981 812,805,232 -2.1%
T17836b(normal) ghc/alloc 45,437,680 45,057,120 -0.8%
T18223(normal) ghc/alloc 734,732,288 646,329,352 -12.0% GOOD
T3064(normal) ghc/alloc 180,023,717 182,061,608 +1.1%
T9630(normal) ghc/alloc 1,523,682,706 1,492,863,632 -2.0% GOOD
T9961(normal) ghc/alloc 358,760,821 368,223,992 +2.6% BAD
geo. mean -0.3%
minimum -25.0%
maximum +5.4%
Metric Decrease:
LargeRecord
T18223
T9630
Metric Increase:
T10421
T16577
T9961
- - - - -
30 changed files:
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/TyCl/Instance.hs
- compiler/GHC/ThToHs.hs
- compiler/GHC/Types/Demand.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/TyThing.hs
- compiler/Language/Haskell/Syntax/Decls.hs
- docs/users_guide/9.6.1-notes.rst
- docs/users_guide/exts/data_kinds.rst
- + docs/users_guide/exts/type_data.rst
- docs/users_guide/exts/types.rst
- libraries/Cabal
- libraries/ghc-boot-th/GHC/LanguageExtensions/Type.hs
- testsuite/tests/arityanal/should_compile/Arity11.stderr
- testsuite/tests/arityanal/should_compile/Arity14.stderr
- testsuite/tests/arityanal/should_compile/Arity16.stderr
- testsuite/tests/driver/T4437.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c434c0a4977637dec45a29755b39c50930fe597d...c20396faef0cc3c18e57c977ac439a00d19e16ed
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c434c0a4977637dec45a29755b39c50930fe597d...c20396faef0cc3c18e57c977ac439a00d19e16ed
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/20220928/8870cadc/attachment-0001.html>
More information about the ghc-commits
mailing list