[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 6 commits: CorePrep: Attach evaldUnfolding to floats to detect more values
Marge Bot (@marge-bot)
gitlab at gitlab.haskell.org
Sat Oct 26 12:13:56 UTC 2024
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
55e4b9f2 by Sebastian Graf at 2024-10-25T07:01:54-04:00
CorePrep: Attach evaldUnfolding to floats to detect more values
See `Note [Pin evaluatedness on floats]`.
- - - - -
9f57c96d by Sebastian Graf at 2024-10-25T07:01:54-04:00
Make DataCon workers strict in strict fields (#20749)
This patch tweaks `exprIsConApp_maybe`, `exprIsHNF` and friends, and Demand
Analysis so that they exploit and maintain strictness of DataCon workers. See
`Note [Strict fields in Core]` for details.
Very little needed to change, and it puts field seq insertion done by Tag
Inference into a new perspective: That of *implementing* strict field semantics.
Before Tag Inference, DataCon workers are strict. Afterwards they are
effectively lazy and field seqs happen around use sites. History has shown
that there is no other way to guarantee taggedness and thus the STG Strict Field
Invariant.
Knock-on changes:
* I reworked the whole narrative around "Tag inference".
It's now called "EPT enforcement" and I recycyled the different overview
Notes into `Note [EPT enforcement]`.
* `exprIsHNF` previously used `exprOkForSpeculation` on unlifted arguments
instead of recursing into `exprIsHNF`. That regressed the termination
analysis in CPR analysis (which simply calls out to `exprIsHNF`), so I made
it call `exprOkForSpeculation`, too.
* There's a small regression in Demand Analysis, visible in the changed test
output of T16859: Previously, a field seq on a variable would give that
variable a "used exactly once" demand, now it's "used at least once",
because `dmdTransformDataConSig` accounts for future uses of the field
that actually all go through the case binder (and hence won't re-enter the
potential thunk). The difference should hardly be observable.
* The Simplifier's fast path for data constructors only applies to lazy
data constructors now. I observed regressions involving Data.Binary.Put's
`Pair` data type.
* Unfortunately, T21392 does no longer reproduce after this patch, so I marked
it as "not broken" in order to track whether we regress again in the future.
Fixes #20749, the satisfying conclusion of an annoying saga (cf. the ideas
in #21497 and #22475).
Compiler perf generally improves, sometimes drastically:
Baseline
Test Metric value New value Change
--------------------------------------------------------------------------------
ManyConstructors(normal) ghc/alloc 3,629,760,116 3,711,852,800 +2.3% BAD
MultiLayerModulesTH_OneShot(normal) ghc/alloc 2,502,735,440 2,565,282,888 +2.5% BAD
T12707(normal) ghc/alloc 804,399,798 791,807,320 -1.6% GOOD
T17516(normal) ghc/alloc 964,987,744 1,008,383,520 +4.5%
T18140(normal) ghc/alloc 75,381,152 49,860,560 -33.9% GOOD
T18698b(normal) ghc/alloc 232,614,457 184,262,736 -20.8% GOOD
T18923(normal) ghc/alloc 62,002,368 58,301,408 -6.0% GOOD
T20049(normal) ghc/alloc 75,719,168 70,494,368 -6.9% GOOD
T3294(normal) ghc/alloc 1,237,925,833 1,157,638,992 -6.5% GOOD
T9233(normal) ghc/alloc 686,490,105 635,166,688 -7.5% GOOD
geo. mean -0.7%
minimum -33.9%
maximum +4.5%
I looked at T17516. It seems we do a few more simplifier iterations and end up
with a larger program. It seems that some things inline more, while other things
inline less. I don't see low-hanging fruit.
I also looked at MultiLayerModulesTH_OneShot. It appears we generate a strange
join point in the `getUnique` method of `Uniquable GHC.Unit.Types.Module` that
should better call-site inline, but does not. Perhaps with !11492.
NoFib does not seem affected much either:
+-------------------------------++--+------------+-----------+---------------+-----------+
| || | base/ | std. err. | T20749/ (rel) | std. err. |
+===============================++==+============+===========+===============+===========+
| spectral/last-piece || | 7.263e8 | 0.0% | +0.62% | 0.0% |
+===============================++==+============+===========+===============+===========+
| geom mean || | +0.00% | | | |
+-------------------------------++--+------------+-----------+---------------+-----------+
I had a look at last-piece. Nothing changes in stg-final, but there is a bit
of ... movement around Data.Map.insert's use of GHC.Exts.lazy that is gone in
stg-final.
Co-Authored-By: Jaro Reinders <jaro.reinders at gmail.com>
Metric Decrease:
T12707
T18140
T18698b
T18923
T19695
T20049
T3294
T9233
T21839c
Metric Increase:
ManyConstructors
MultiLayerModulesTH_OneShot
- - - - -
0225249a by Simon Peyton Jones at 2024-10-25T07:02:32-04:00
Some renaming
This is a pure refactor, tidying up some inconsistent naming:
isEqPred --> isEqClassPred
isEqPrimPred --> isEqPred
isReprEqPrimPred --> isReprEqPred
mkPrimEqPred --> mkNomEqPred
mkReprPrimEqPred --> mkReprEqPred
mkPrimEqPredRold --> mkEqPredRole
Plus I moved mkNomEqPred, mkReprEqPred, mkEqPredRolek
from GHC.Core.Coercion to GHC.Core.Predicate
where they belong. That means that Coercion imports Predicate
rather than vice versa -- better.
- - - - -
15a3456b by Ryan Hendrickson at 2024-10-25T07:02:32-04:00
compiler: Fix deriving with method constraints
See Note [Inferred contexts from method constraints]
Co-authored-by: Simon Peyton Jones <simon.peytonjones at gmail.com>
- - - - -
dbc77ce8 by Alan Zimmerman at 2024-10-25T18:20:13+01:00
EPA: Remove AddEpann commit 7
EPA: Remove [AddEpAnn] from HYPHEN in Parser.y
The return value is never used, as it is part of the backpack
configuration parsing.
EPA: Remove last [AddEpAnn] usages
Remove residual usage in GHC. It is still used
- In haddock TTG extension point definitions (to be removed)
- Some check-exact residual, to be removed
- Comments around DisambECP in PostProcess
EPA: Clean up [AddEpAnn] from check-exact
There is one left, to be cleaned up when we remove AddEpann itself
EPA: Remove [AddEpAnn] from haddock
The TTG extension points need a value, it is not critical what that
value is, in most cases.
EPA: Remove AddEpAnn from HsRuleAnn
EPA: Remove AddEpAnn from HsCmdArrApp
- - - - -
b07d660f by Simon Peyton Jones at 2024-10-26T08:13:51-04:00
Fix optimisation of InstCo
It turned out (#25387) that the fix to #15725 was not quite right:
commit 48efbc04bd45d806c52376641e1a7ed7278d1ec7
Date: Mon Oct 15 10:25:02 2018 +0200
Fix #15725 with an extra Sym
Optimising InstCo is quite subtle, and the invariants surrounding
the LiftingContext in the coercion optimiser were not stated explicitly.
This patch refactors the InstCo optimisation, and documents these
invariants. See
* Note [Optimising InstCo]
* Note [The LiftingContext in optCoercion]
I also did some refactoring of course:
* Instead of a Bool swap-flag, I am not using GHC.Types.Basic.SwapFlag
* I added some invariant-checking the coercion-construction functions
in GHC.Core.Coercion.Opt. (Sadly these invariants don't hold during
typechecking, becuase the types are un-zonked, so I can't put these
checks in GHC.Core.Coercion.)
- - - - -
30 changed files:
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion.hs-boot
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Predicate.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Dump.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/HsToCore.hs
- compiler/GHC/HsToCore/Pmc/Solver.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/PostProcess.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/16a5f47eb265075cedd86888a5e5da6f167fcb21...b07d660fa52af029eb1291b305fa9fac53f409b8
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/16a5f47eb265075cedd86888a5e5da6f167fcb21...b07d660fa52af029eb1291b305fa9fac53f409b8
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/20241026/af3c96b4/attachment.html>
More information about the ghc-commits
mailing list