[Git][ghc/ghc][wip/simplifier-tweaks] 20 commits: Bump bytestring submodule to something closer to 0.12.1
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Mon Feb 5 23:22:39 UTC 2024
Simon Peyton Jones pushed to branch wip/simplifier-tweaks at Glasgow Haskell Compiler / GHC
Commits:
27020458 by Matthew Craven at 2024-02-03T01:53:26-05:00
Bump bytestring submodule to something closer to 0.12.1
...mostly so that 16d6b7e835ffdcf9b894e79f933dd52348dedd0c
(which reworks unaligned writes in Builder) and the stuff in
https://github.com/haskell/bytestring/pull/631 can see wider testing.
The less-terrible code for unaligned writes used in Builder on
hosts not known to be ulaigned-friendly also takes less effort
for GHC to compile, resulting in a metric decrease for T21839c
on some platforms.
The metric increase on T21839r is caused by the unrelated commit
750dac33465e7b59100698a330b44de7049a345c. It perhaps warrants
further analysis and discussion (see #23822) but is not critical.
Metric Decrease:
T21839c
Metric Increase:
T21839r
- - - - -
cdddeb0f by Rodrigo Mesquita at 2024-02-03T01:54:02-05:00
Work around autotools setting C11 standard in CC/CXX
In autoconf >=2.70, C11 is set by default for $CC and $CXX via the
-std=...11 flag. In this patch, we split the "-std" flag out of the $CC
and $CXX variables, which we traditionally assume to be just the
executable name/path, and move it to $CFLAGS/$CXXFLAGS instead.
Fixes #24324
- - - - -
5ff7cc26 by Apoorv Ingle at 2024-02-03T13:14:46-06:00
Expand `do` blocks right before typechecking using the `HsExpansion` philosophy.
- Fixes #18324 #20020 #23147 #22788 #15598 #22086 #21206
- The change is detailed in
- Note [Expanding HsDo with HsExpansion] in `GHC.Tc.Gen.Do`
- Note [Doing HsExpansion in the Renamer vs Typechecker] in `GHC.Rename.Expr`
expains the rational of doing expansions in type checker as opposed to in the renamer
- Adds new datatypes:
- `GHC.Hs.Expr.XXExprGhcRn`: new datatype makes this expansion work easier
1. Expansion bits for Expressions, Statements and Patterns in (`ExpandedThingRn`)
2. `PopErrCtxt` a special GhcRn Phase only artifcat to pop the previous error message in the error context stack
- `GHC.Basic.Origin` now tracks the reason for expansion in case of Generated
This is useful for type checking cf. `GHC.Tc.Gen.Expr.tcExpr` case for `HsLam`
- Kills `HsExpansion` and `HsExpanded` as we have inlined them in `XXExprGhcRn` and `XXExprGhcTc`
- Ensures warnings such as
1. Pattern match checks
2. Failable patterns
3. non-() return in body statements are preserved
- Kill `HsMatchCtxt` in favor of `TcMatchAltChecker`
- Testcases:
* T18324 T20020 T23147 T22788 T15598 T22086
* T23147b (error message check),
* DoubleMatch (match inside a match for pmc check)
* pattern-fails (check pattern match with non-refutable pattern, eg. newtype)
* Simple-rec (rec statements inside do statment)
* T22788 (code snippet from #22788)
* DoExpanion1 (Error messages for body statments)
* DoExpansion2 (Error messages for bind statements)
* DoExpansion3 (Error messages for let statements)
Also repoint haddock to the right submodule so that the test (haddockHypsrcTest) pass
Metric Increase 'compile_time/bytes allocated':
T9020
The testcase is a pathalogical example of a `do`-block with many statements that do nothing.
Given that we are expanding the statements into function binds, we will have to bear
a (small) 2% cost upfront in the compiler to unroll the statements.
- - - - -
0df8ce27 by Vladislav Zavialov at 2024-02-04T03:55:14-05:00
Reduce parser allocations in allocateCommentsP
In the most common case, the comment queue is empty, so we can skip the
work of processing it. This reduces allocations by about 10% in the
parsing001 test.
Metric Decrease:
MultiLayerModulesRecomp
parsing001
- - - - -
cfd68290 by Simon Peyton Jones at 2024-02-05T17:58:33-05:00
Stop dropping a case whose binder is demanded
This MR fixes #24251.
See Note [Case-to-let for strictly-used binders]
in GHC.Core.Opt.Simplify.Iteration, plus #24251, for
lots of discussion.
Final Nofib changes over 0.1%:
+-----------------------------------------
| imaginary/digits-of-e2 -2.16%
| imaginary/rfib -0.15%
| real/fluid -0.10%
| real/gamteb -1.47%
| real/gg -0.20%
| real/maillist +0.19%
| real/pic -0.23%
| real/scs -0.43%
| shootout/n-body -0.41%
| shootout/spectral-norm -0.12%
+========================================
| geom mean -0.05%
Pleasingly, overall executable size is down by just over 1%.
Compile times (in perf/compiler) wobble around a bit +/- 0.5%, but the
geometric mean is -0.1% which seems good.
- - - - -
e4d137bb by Simon Peyton Jones at 2024-02-05T17:58:33-05:00
Add Note [Bangs in Integer functions]
...to document the bangs in the functions in GHC.Num.Integer
- - - - -
ce90f12f by Andrei Borzenkov at 2024-02-05T17:59:09-05:00
Hide WARNING/DEPRECATED namespacing under -XExplicitNamespaces (#24396)
- - - - -
cd4636e5 by Simon Peyton Jones at 2024-02-05T23:18:11+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
- - - - -
551dd42c by Simon Peyton Jones at 2024-02-05T23:21:55+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
- - - - -
7593b373 by Simon Peyton Jones at 2024-02-05T23:21:55+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.
- - - - -
9aa87e70 by Simon Peyton Jones at 2024-02-05T23:21:55+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
- - - - -
74725e2a by Simon Peyton Jones at 2024-02-05T23:21:55+00:00
Unused variable wibbles
- - - - -
9452a5f4 by Simon Peyton Jones at 2024-02-05T23:21:55+00:00
More import wibbles
- - - - -
a918ca47 by Simon Peyton Jones at 2024-02-05T23:21:55+00:00
More imports
- - - - -
d9e9fb41 by Simon Peyton Jones at 2024-02-05T23:21:55+00:00
More wibbles
- - - - -
aefae0d4 by Simon Peyton Jones at 2024-02-05T23:21:55+00:00
More on floating join points
* Get rid of the "join ceiling" which I have always hated
* Float joins to top level in final pass only
(needs documenting--see my GHC log)
* Refactor wantToFloat so that it applies to Rec and NonRec uniformly
- - - - -
cf1b1463 by Simon Peyton Jones at 2024-02-05T23:21:55+00:00
Comments about floating joins
- - - - -
dffef2cb by Simon Peyton Jones at 2024-02-05T23:21:55+00:00
Improve occurrence analyis for bottoming function calls
See Note [Bottoming function calls]
- - - - -
73f9204d by Simon Peyton Jones at 2024-02-05T23:22:21+00:00
Test output wibbles
- - - - -
47be08e0 by Simon Peyton Jones at 2024-02-05T23:22:21+00:00
More testsuite wibbles
- - - - -
18 changed files:
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/FloatOut.hs
- compiler/GHC/Core/Opt/Monad.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/Pipeline.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
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e9f9f06839b94a10a0b4a8f81a903a639e2e0034...47be08e0835754f64f74c0fb0778edb451481459
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e9f9f06839b94a10a0b4a8f81a903a639e2e0034...47be08e0835754f64f74c0fb0778edb451481459
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/20240205/47d20a34/attachment-0001.html>
More information about the ghc-commits
mailing list