[Git][ghc/ghc][wip/simplifier-tweaks] 4 commits: Several improvements to the handling of coercions
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Tue Jan 23 12:28:09 UTC 2024
Simon Peyton Jones pushed to branch wip/simplifier-tweaks at Glasgow Haskell Compiler / GHC
Commits:
232301de by Simon Peyton Jones at 2024-01-22T13:28:08+00:00
Several improvements to the handling of coercions
* Make `mkSymCo` and `mkInstCo` smarter
Fixes #23642
* Fix return role of `SelCo` in the coercion optimiser.
Fixes #23617
* Make the coercion optimiser `opt_trans_rule` work better for newtypes
Fixes #23619
- - - - -
badc5de4 by Simon Peyton Jones at 2024-01-22T13:28:08+00:00
Simplifier improvements
This MR started as: allow the simplifer to do more in one pass,
arising from places I could see the simplifier taking two iterations
where one would do. But it turned into a larger project, because
these changes unexpectedly made inlining blow up, especially join
points in deeply-nested cases.
The net result is good: a 1.5% improvement in compile time. The table
below shows changes over 1%.
The main changes are:
* The SimplEnv now has a seInlineDepth field, which says how deep
in unfoldings we are. See Note [Inline depth] in Simplify.Env
* Avoid repeatedly simplifying coercions.
see Note [Avoid re-simplifying coercions] in Simplify.Iteration
As you'll see from the Note, this makes use of the seInlineDepth.
* Allow Simplify.Utils.postInlineUnconditionally to inline variables
that are used exactly once. See Note [Post-inline for single-use things].
* Allow Simplify.Iteration.simplAuxBind to inline used-once things.
This is another part of Note [Post-inline for single-use things], and
is really good for reducing simplifier iterations in situations like
case K e of { K x -> blah }
wher x is used once in blah.
* Make GHC.Core.SimpleOpt.exprIsConApp_maybe do some simple case
elimination. Note [Case elim in exprIsConApp_maybe]
* Many new or rewritten Notes. E.g. Note [Avoiding simplifying repeatedly]
Join points
~~~~~~~~~~~
* Be very careful about inlining join points. See
Note [Duplicating join points] in GHC.Core.Opt.Simplify.Iteration
* When making join points, don't do so if the join point is so small
it will immediately be inlined; check uncondInlineJoin.
* When considering inlining a join point, never do so unless
there is a positive gain: see (DJ5) in Note [Duplicating join points].
* Do not float join points at all, except to top level.
See GHC.Core.Opt.SetLevels.dontFloatNonRec
* Do not add an unfolding to a join point at birth. This is a tricky one
and has a long Note [Do not add unfoldings to join points at birth]
It shows up in two places
- In `mkDupableAlt` do not add an inlining
- (trickier) In `simplLetUnfolding` don't add an unfolding for a
fresh join point
I am not fully satisifed with this, but it works and is well documented.
* In GHC.Core.Unfold.sizeExpr, make jumps small, so that we don't penalise
having a non-inlined join point.
* Use plan A for dataToTag and tagToEnum
I discovered that GHC.HsToCore.Pmc.Solver.Types.trvVarInfo was very
delicately balanced. It's a small, heavily used, overloaded function
and it's important that it inlines. By a fluke it was before, but at
various times in my journey it stopped doing so. So I added an INLINE
pragma to it.
Metrics: compile_time/bytes allocated
------------------------------------------------
CoOpt_Singletons(normal) -8.2% GOOD
LargeRecord(normal) -22.7% GOOD
PmSeriesS(normal) -4.1%
PmSeriesT(normal) -3.1%
PmSeriesV(normal) -1.6%
T11195(normal) -1.9%
T12227(normal) -19.9% GOOD
T12545(normal) -5.4%
T12707(normal) -2.1% GOOD
T13253-spj(normal) -13.1% GOOD
T13386(normal) -1.6%
T14766(normal) -2.2% GOOD
T15630a(normal) NEW
T15703(normal) -13.5% GOOD
T16577(normal) -4.3% GOOD
T17096(normal) -4.4%
T17516(normal) -0.2%
T18223(normal) -16.3% GOOD
T18282(normal) -5.3% GOOD
T18730(optasm) NEW
T18923(normal) -3.7% GOOD
T21839c(normal) -2.3% GOOD
T3064(normal) -1.3%
T5030(normal) -16.1% GOOD
T5321Fun(normal) -1.5%
T6048(optasm) -11.8% GOOD
T783(normal) -1.4%
T8095(normal) -5.9% GOOD
T9630(normal) -5.1% GOOD
T9020(optasm) +1.5%
T18698a(normal) +1.5% BAD
T14683(normal) +1.2%
DsIncompleteRecSel3(normal) +1.2%
MultiComponentModulesRecomp(normal) +1.0%
MultiLayerModulesRecomp(normal) +1.9%
MultiLayerModulesTH_Make(normal) +1.4%
T10421(normal) +1.9% BAD
T10421a(normal) +3.0%
T13056(optasm) +1.1%
T13253(normal) +1.0%
T1969(normal) +1.1% BAD
T15304(normal) +1.7%
T9675(optasm) +1.2%
T9961(normal) +2.4% BAD
geo. mean -1.5%
minimum -22.7%
maximum +3.0%
Metric Decrease:
CoOpt_Singletons
LargeRecord
T12227
T12707
T12990
T13253-spj
T13536a
T14766
T15703
T16577
T18223
T18282
T18923
T21839c
T5030
T6048
T8095
T9630
Metric Increase:
T10421
T18698a
T1969
T9961
- - - - -
a7b15349 by Simon Peyton Jones at 2024-01-22T13:28:08+00:00
Improve postInlineUnconditionally
This commit adds two things to postInlineUnconditionally:
1. Do not postInlineUnconditionally join point, ever.
Doing so does not reduce allocation, which is the main point,
and with join points that are used a lot it can bloat code.
See point (1) of Note [Duplicating join points] in
GHC.Core.Opt.Simplify.Iteration.
2. Do not postInlineUnconditionally a strict (demanded) binding.
It will not allocate a thunk (it'll turn into a case instead)
so again the main point of inlining it doesn't hold. Better
to check per-call-site.
- - - - -
9f5fa612 by Simon Peyton Jones at 2024-01-23T12:26:02+00:00
More wibbles
* Inline join points whose RHS just calls another join point
* Don't float join points at all (SetLevels)
* Ensure that WorkWrap preserves lambda binders, in case of join points
- - - - -
30 changed files:
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Inline.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Monad.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Stats.hs
- compiler/GHC/Core/Opt/WorkWrap.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Unfold/Make.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/HsToCore/Pmc/Solver/Types.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Tc/Solver/Equality.hs
- compiler/GHC/Types/Id.hs
- compiler/GHC/Types/Tickish.hs
- testsuite/tests/driver/inline-check.stderr
- testsuite/tests/numeric/should_compile/T19641.stderr
- testsuite/tests/perf/compiler/T15630.hs
- + testsuite/tests/perf/compiler/T15630a.hs
- testsuite/tests/simplCore/should_compile/T18730.hs → testsuite/tests/perf/compiler/T18730.hs
- testsuite/tests/simplCore/should_compile/T18730_A.hs → testsuite/tests/perf/compiler/T18730_A.hs
- testsuite/tests/perf/compiler/all.T
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4ff310c8e4b75049add18c2025f32657bc2e0af...9f5fa612e0068d10ddf383a06fba11d090765c29
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4ff310c8e4b75049add18c2025f32657bc2e0af...9f5fa612e0068d10ddf383a06fba11d090765c29
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/20240123/843958d7/attachment.html>
More information about the ghc-commits
mailing list