[Git][ghc/ghc][wip/T21470] 13 commits: Apply some tricks to speed up core lint.
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Fri Sep 30 07:52:47 UTC 2022
Simon Peyton Jones pushed to branch wip/T21470 at Glasgow Haskell Compiler / GHC
Commits:
c2d73cb4 by Andreas Klebinger at 2022-09-28T15:07:30-04:00
Apply some tricks to speed up core lint.
Below are the noteworthy changes and if given their impact on compiler
allocations for a type heavy module:
* Use the oneShot trick on LintM
* Use a unboxed tuple for the result of LintM: ~6% reduction
* Avoid a thunk for the result of typeKind in lintType: ~5% reduction
* lint_app: Don't allocate the error msg in the hot code path: ~4%
reduction
* lint_app: Eagerly force the in scope set: ~4%
* nonDetCmpType: Try to short cut using reallyUnsafePtrEquality#: ~2%
* lintM: Use a unboxed maybe for the `a` result: ~12%
* lint_app: make go_app tail recursive to avoid allocating the go function
as heap closure: ~7%
* expandSynTyCon_maybe: Use a specialized data type
For a less type heavy module like nofib/spectral/simple compiled with
-O -dcore-lint allocations went down by ~24% and compile time by ~9%.
-------------------------
Metric Decrease:
T1969
-------------------------
- - - - -
b74b6191 by sheaf at 2022-09-28T15:08:10-04:00
matchLocalInst: do domination analysis
When multiple Given quantified constraints match a Wanted, and there is
a quantified constraint that dominates all others, we now pick it
to solve the Wanted.
See Note [Use only the best matching quantified constraint].
For example:
[G] d1: forall a b. ( Eq a, Num b, C a b ) => D a b
[G] d2: forall a . C a Int => D a Int
[W] {w}: D a Int
When solving the Wanted, we find that both Givens match, but we pick
the second, because it has a weaker precondition, C a Int, compared
to (Eq a, Num Int, C a Int). We thus say that d2 dominates d1;
see Note [When does a quantified instance dominate another?].
This domination test is done purely in terms of superclass expansion,
in the function GHC.Tc.Solver.Interact.impliedBySCs. We don't attempt
to do a full round of constraint solving; this simple check suffices
for now.
Fixes #22216 and #22223
- - - - -
2a53ac18 by Simon Peyton Jones at 2022-09-28T17:49:09-04:00
Improve aggressive specialisation
This patch fixes #21286, by not unboxing dictionaries in
worker/wrapper (ever). The main payload is tiny:
* In `GHC.Core.Opt.DmdAnal.finaliseArgBoxities`, do not unbox
dictionaries in `get_dmd`. See Note [Do not unbox class dictionaries]
in that module
* I also found that imported wrappers were being fruitlessly
specialised, so I fixed that too, in canSpecImport.
See Note [Specialising imported functions] point (2).
In doing due diligence in the testsuite I fixed a number of
other things:
* Improve Note [Specialising unfoldings] in GHC.Core.Unfold.Make,
and Note [Inline specialisations] in GHC.Core.Opt.Specialise,
and remove duplication between the two. The new Note describes
how we specialise functions with an INLINABLE pragma.
And simplify the defn of `spec_unf` in `GHC.Core.Opt.Specialise.specCalls`.
* Improve Note [Worker/wrapper for INLINABLE functions] in
GHC.Core.Opt.WorkWrap.
And (critially) make an actual change which is to propagate the
user-written pragma from the original function to the wrapper; see
`mkStrWrapperInlinePrag`.
* Write new Note [Specialising imported functions] in
GHC.Core.Opt.Specialise
All this has a big effect on some compile times. This is
compiler/perf, showing only changes over 1%:
Metrics: compile_time/bytes allocated
-------------------------------------
LargeRecord(normal) -50.2% GOOD
ManyConstructors(normal) +1.0%
MultiLayerModulesTH_OneShot(normal) +2.6%
PmSeriesG(normal) -1.1%
T10547(normal) -1.2%
T11195(normal) -1.2%
T11276(normal) -1.0%
T11303b(normal) -1.6%
T11545(normal) -1.4%
T11822(normal) -1.3%
T12150(optasm) -1.0%
T12234(optasm) -1.2%
T13056(optasm) -9.3% GOOD
T13253(normal) -3.8% GOOD
T15164(normal) -3.6% GOOD
T16190(normal) -2.1%
T16577(normal) -2.8% GOOD
T16875(normal) -1.6%
T17836(normal) +2.2%
T17977b(normal) -1.0%
T18223(normal) -33.3% GOOD
T18282(normal) -3.4% GOOD
T18304(normal) -1.4%
T18698a(normal) -1.4% GOOD
T18698b(normal) -1.3% GOOD
T19695(normal) -2.5% GOOD
T5837(normal) -2.3%
T9630(normal) -33.0% GOOD
WWRec(normal) -9.7% GOOD
hard_hole_fits(normal) -2.1% GOOD
hie002(normal) +1.6%
geo. mean -2.2%
minimum -50.2%
maximum +2.6%
I diligently investigated some of the big drops.
* Caused by not doing w/w for dictionaries:
T13056, T15164, WWRec, T18223
* Caused by not fruitlessly specialising wrappers
LargeRecord, T9630
For runtimes, here is perf/should+_run:
Metrics: runtime/bytes allocated
--------------------------------
T12990(normal) -3.8%
T5205(normal) -1.3%
T9203(normal) -10.7% GOOD
haddock.Cabal(normal) +0.1%
haddock.base(normal) -1.1%
haddock.compiler(normal) -0.3%
lazy-bs-alloc(normal) -0.2%
------------------------------------------
geo. mean -0.3%
minimum -10.7%
maximum +0.1%
I did not investigate exactly what happens in T9203.
Nofib is a wash:
+-------------------------------++--+-----------+-----------+
| || | tsv (rel) | std. err. |
+===============================++==+===========+===========+
| real/anna || | -0.13% | 0.0% |
| real/fem || | +0.13% | 0.0% |
| real/fulsom || | -0.16% | 0.0% |
| real/lift || | -1.55% | 0.0% |
| real/reptile || | -0.11% | 0.0% |
| real/smallpt || | +0.51% | 0.0% |
| spectral/constraints || | +0.20% | 0.0% |
| spectral/dom-lt || | +1.80% | 0.0% |
| spectral/expert || | +0.33% | 0.0% |
+===============================++==+===========+===========+
| geom mean || | | |
+-------------------------------++--+-----------+-----------+
I spent quite some time investigating dom-lt, but it's pretty
complicated. See my note on !7847. Conclusion: it's just a delicate
inlining interaction, and we have plenty of those.
Metric Decrease:
LargeRecord
T13056
T13253
T15164
T16577
T18223
T18282
T18698a
T18698b
T19695
T9630
WWRec
hard_hole_fits
T9203
- - - - -
addeefc0 by Simon Peyton Jones at 2022-09-28T17:49:09-04:00
Refactor UnfoldingSource and IfaceUnfolding
I finally got tired of the way that IfaceUnfolding reflected
a previous structure of unfoldings, not the current one. This
MR refactors UnfoldingSource and IfaceUnfolding to be simpler
and more consistent.
It's largely just a refactor, but in UnfoldingSource (which moves
to GHC.Types.Basic, since it is now used in IfaceSyn too), I
distinguish between /user-specified/ and /system-generated/ stable
unfoldings.
data UnfoldingSource
= VanillaSrc
| StableUserSrc -- From a user-specified pragma
| StableSystemSrc -- From a system-generated unfolding
| CompulsorySrc
This has a minor effect in CSE (see the use of isisStableUserUnfolding
in GHC.Core.Opt.CSE), which I tripped over when working on
specialisation, but it seems like a Good Thing to know anyway.
- - - - -
7be6f9a4 by Simon Peyton Jones at 2022-09-28T17:49:09-04:00
INLINE/INLINEABLE pragmas in Foreign.Marshal.Array
Foreign.Marshal.Array contains many small functions, all of which are
overloaded, and which are critical for performance. Yet none of them
had pragmas, so it was a fluke whether or not they got inlined.
This patch makes them all either INLINE (small ones) or
INLINEABLE and hence specialisable (larger ones).
See Note [Specialising array operations] in that module.
- - - - -
b0c89dfa by Jade Lovelace at 2022-09-28T17:49:49-04:00
Export OnOff from GHC.Driver.Session
I was working on fixing an issue where HLS was trying to pass its
DynFlags to HLint, but didn't pass any of the disabled language
extensions, which HLint would then assume are on because of their
default values.
Currently it's not possible to get any of the "No" flags because the
`DynFlags.extensions` field can't really be used since it is [OnOff
Extension] and OnOff is not exported.
So let's export it.
- - - - -
2f050687 by Bodigrim at 2022-09-28T17:50:28-04:00
Avoid Data.List.group; prefer Data.List.NonEmpty.group
This allows to avoid further partiality, e. g., map head . group is
replaced by map NE.head . NE.group, and there are less panic calls.
- - - - -
bc0020fa by M Farkas-Dyck at 2022-09-28T22:51:59-04:00
Clean up `findWiredInUnit`. In particular, avoid `head`.
- - - - -
6a2eec98 by Bodigrim at 2022-09-28T22:52:38-04:00
Eliminate headFS, use unconsFS instead
A small step towards #22185 to avoid partial functions + safe implementation
of `startsWithUnderscore`.
- - - - -
5a535172 by Sebastian Graf at 2022-09-29T17:04:20+02:00
Demand: Format Call SubDemands `Cn(sd)` as `C(n,sd)` (#22231)
Justification in #22231. Short form: In a demand like `1C1(C1(L))`
it was too easy to confuse which `1` belongs to which `C`. Now
that should be more obvious.
Fixes #22231
- - - - -
ea0083bf by Bryan Richter at 2022-09-29T15:48:38-04:00
Revert "ci: enable parallel compression for xz"
Combined wxth XZ_OPT=9, this blew the memory capacity of CI runners.
This reverts commit a5f9c35f5831ef5108e87813a96eac62803852ab.
- - - - -
2f34e1b0 by Simon Peyton Jones at 2022-09-30T08:54:40+01:00
Make the specialiser handle polymorphic specialisation
Ticket #13873 unexpectedly showed that a SPECIALISE pragma made a
program run (a lot) slower, because less specialisation took place
overall. It turned out that the specialiser was missing opportunities
because of quantified type variables.
It was quite easy to fix. The story is given in
Note [Specialising polymorphic dictionaries]
Two other minor fixes in the specialiser
* There is no benefit in specialising data constructor /wrappers/.
(They can appear overloaded because they are given a dictionary
to store in the constructor.) Small guard in canSpecImport.
* There was a buglet in the UnspecArg case of specHeader, in the
case where there is a dead binder. We need a LitRubbish filler
for the specUnfolding stuff. I expanded
Note [Drop dead args from specialisations] to explain.
There is a 4% increase in compile time for T13056, because we generate
more specialised code. This seems OK.
Metric Increase:
T13056
- - - - -
e57eefb8 by Simon Peyton Jones at 2022-09-30T08:54:41+01:00
Fix binder-swap bug
This patch fixes #21229 / #21470 properly, by avoiding doing a
binder-swap on dictionary Ids. This is pretty subtle, and explained
in Note [Care with binder-swap on dictionaries].
This allows us to restore a feature to the specialiser that we had
to revert: see Note [Specialising polymorphic dictionaries].
I als modularised things, using a new function scrutBinderSwap_maybe
in all the places where we are (effectively) doing a binder-swap,
notably
* Simplify.Iteration.addAltUnfoldings
* SpecConstr.extendCaseBndrs
In Simplify.Iteration.addAltUnfoldings I also eliminated a guard
Many <- idMult case_bndr
because we concluded, in #22123, that it was doing no good.
- - - - -
30 changed files:
- .gitlab/ci.sh
- compiler/GHC/Cmm/Switch.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/Reg/Liveness.hs
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/FamInstEnv.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CSE.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/Stats.hs
- compiler/GHC/Core/Opt/WorkWrap.hs
- compiler/GHC/Core/Ppr.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/Tidy.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Unfold/Make.hs
- compiler/GHC/CoreToIface.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f7a033ac30301c942594c59e8ad5f03a3e2ecd3e...e57eefb80e83061c03e49dd2fd91f29635181625
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f7a033ac30301c942594c59e8ad5f03a3e2ecd3e...e57eefb80e83061c03e49dd2fd91f29635181625
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/20220930/d38a358c/attachment-0001.html>
More information about the ghc-commits
mailing list