[Git][ghc/ghc][wip/T20264] 42 commits: Tidy up the handling of `assert`

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Tue Dec 17 12:13:34 UTC 2024



Simon Peyton Jones pushed to branch wip/T20264 at Glasgow Haskell Compiler / GHC


Commits:
64756530 by Simon Peyton Jones at 2024-12-14T22:28:04-05:00
Tidy up the handling of `assert`

Fixes #25493

- - - - -
8658fbc1 by Rodrigo Mesquita at 2024-12-14T22:28:41-05:00
base: displayException for SomeAsyncException

Provide a better implementation of `SomeException` for
`SomeAsyncException`.
The previous, implicit, implementation, would not use the
`displayException` of the exception wrapped by `SomeAsyncException`.

Implements CLC-Proposal#309

Closes #25513

- - - - -
2d3a0a70 by ARATA Mizuki at 2024-12-15T18:35:30-05:00
LLVM: When emitting a vector literal with ppTypeLit, include the type information

Fixes #25561

- - - - -
bfacc086 by Simon Peyton Jones at 2024-12-15T18:36:05-05:00
Fix signature lookup in instance declarations

This fixes a bug introduced by the fix to #16610

- - - - -
80f0e02d by Simon Peyton Jones at 2024-12-16T17:13:52+00:00
Improve GHC build times

Two small changes

* In GHC.Data.Unboxed, never omit interface pragmas.  In "fast builds"
  one might omit them generally, but doing so gives very bad
  performance for code that imports this module.

* In GHC.Hs.Dump don't do type-class specialisation.  For some reason
  it goes mad and generates vast amounts of useless code.  See #25463.

- - - - -
175a1355 by Simon Peyton Jones at 2024-12-16T17:13:52+00:00
Refactor Lint

Refactor Lint for two reasons:

* To improve performance
* To prepare for type-lets

The big changes are all in GHC.Core.Lint:

* Change the main APIs:
  * `lintType` returns nothing rather than returning a `LintedType`;
  * `lintCoercion` return nothing rather than returning a `LintedCoercion`
  Reason: these functions did a lot of allocation to return a substituted
  type/coercion that was often discarded, or used only to extract its kind.

  Instead we now return nothing, and, when needed, extract the kind and
  substitute.

* Applications are treated as a whole, by `lintApp`.  By treating
  multiple arguments all at once we avoid performing multiple
  substitutions, each substituting a single type variable. This can
  make an absolutely huge difference.

Overall this led to a pretty massive rewrite of Lint, with many smaller
changes.

Smaller chnages elsewhere

* Rename `GHC.Core.TyCo.Subst.getSubstInScope` to `substInScopeSet` for consistency

* Define and use `GHC.Core.Type.liftedTypeOrConstraintKind`

Performance. This MR someimtes gives gives a very large improvement in
compile time, when Lint is on.  here is a selection of changes over 5%
in perf/compiler (with -dcore-lint)

      T25196                       -97.0%
      T14766                       -89.7%
      T14683                       -74.4%
      T5631                        -60.9%
      T20261                       -56.7%
      T18923                       -17.6%
      T13035                       -15.8%
      T6048                        -15.8%
      CoOpt_Read                   -14.4%
      T9630                        -10.9%
      T5642                         -7.3%

Eliminating the egregious offenders is a big win.

However, in some cases the compiler allocation /increases/. Here ae the
changes over 1%:

      T9961                          1.5%
      T8095                          2.8%
      T14052                         3.9%
      T12545                         4.5%
      T14052Type                     5.5%
      T5030                          8.0%
      T5321Fun                       8.3%
      T3064                         12.7%
      CoOpt_Singletons              15.6%
      T9198                         16.0%
      LargeRecord                   18.1%

I looked at the two biggest increases in compile-time bytes allocated.  Interestingly,
they both show substantial *decreases* in actual compile time, due to much smaller GC times.
I'm honestly not sure either why the allocation increases, or why the GC time decreases;
but I'm going to take the win!

    T9198
                 Baseline            With patch
    No Lint
      Alloc       44.6M              44.6M
      Mut time    0.23s              0.22s
      GC time     0.21s              0.21s

    With Lint
      Alloc       309M               360M
      Mut time    1.51s              0.85s
      GC time     2.97s              0.25s

    -------------------
    LargeRecord
                 Baseline            With patch
    No Lint
      Alloc       1.37G              1.37G
      Mut time    2.33s              2.33s
      GC time     2.40s              2.42s

    With Lint
      Alloc       3.4G               4.0G
      Mut time    6.02s              5.68s
      GC time     3.67s              3.03s

IMPORTANT NOTE: These changes don't show up in CI because in CI the
tests in perf/compiler are all run with -dcore-lint switched off.  I
gathered this data with some manual runs.

- - - - -
8ef2dad6 by Simon Peyton Jones at 2024-12-17T02:48:09-05:00
Add Note [Typechecking overloaded literals]

See #25494.

- - - - -
459b0271 by Joseph Fourment at 2024-12-17T10:15:43+00:00
compiler: introduce type variable unfoldings

The plan for #20264 is to introduce let-bound types to have observable sharing in types.
To avoid the need to carry an environment when dealing with occurrences of these type variables,
we embed the types they're bound to (if any) in a `tv_unfolding :: Maybe Type` attribute.
This way, one can look through let-bound type variables using `coreView` and friends.
In particular, definitional equality looks through unfoldings.

- - - - -
d9cadd1a by Joseph Fourment at 2024-12-17T10:15:43+00:00
simple-opt: don't inline type-lets

- - - - -
ccc7b2e2 by Joseph Fourment at 2024-12-17T10:15:43+00:00
specialise: fix type-lets in DFun unfoldings

During specialisation, a dictionary being specialised gets a new unfolding by turning
`DFun \ bndrs      -> MkD @<T1> ... @<Tm> <op1> ... <opn>` into
`DFun \ spec_bndrs -> MkD @((\ bndrs -> TYPE: <T1>) spec_args) ... ((\ bndrs -> <opn>) spec_args)`
which in turns gets beta-reduced into
`DFun \ spec_bndrs -> MkD (let { bndrs = spec_args } in TYPE: <T1>) ... (let { bndrs = spec_args } in <opn>)`.
Previously, such let binders would immediately be substituted into the type so it didn't cause any issue,
but now we want to avoid inlining.
Arguments of the form `let { bndrs = spec_args } in TYPE: <T1>` are not considered as type arguments since they're
not of the canonical form `TYPE: something`.
This commit restores the previous behavior of substituting the specialised type arguments.
Alternatively, we could attach some floated type bindings to `DFun`s.

- - - - -
3967b14e by Joseph Fourment at 2024-12-17T10:15:43+00:00
occur-anal: implement occurence analysis for type variables

In order to find out let-bound type variables that are used only once, in the hope of inlining them,
we need to track type variables as well in the occurrence analiser. Just like Id's, we attach an
`OccInfo` to each (immutable) type variable, and we walk into types and coercions to accurately gather
occurrences.

- - - - -
6cbf2a78 by Joseph Fourment at 2024-12-17T10:15:43+00:00
simplifier: don't inline type-lets

Keep propagating type-lets further down the pipeline, in the simplifier.
We also update CallArity, CprAnal, DmdAnal, WorkWrap, and Specialise to ignore type-lets.

- - - - -
e8933d98 by Joseph Fourment at 2024-12-17T10:15:43+00:00
prep: make type-lets pass through CorePrep

As a first attempt, ignore type-lets in CorePrep to avoid crashes.
However, this is not enough: CorePrep also does some let-floating.
If we don't float type-lets along with value-level let-bindings,
the latter can float out of the scope of a type variable in use.

- - - - -
258da9ca by Joseph Fourment at 2024-12-17T10:15:44+00:00
simple-opt: fix simple_type_bind

Also:
- Inline small types using a new typeIsSmallEnoughToInline predicate
- Inline single-occurrence variables

- - - - -
104a8988 by Joseph Fourment at 2024-12-17T10:15:44+00:00
simple-opt: make beta-reduction use simple_bind_type

- - - - -
becbd35e by Joseph Fourment at 2024-12-17T10:15:44+00:00
iface: add IfaceTypeLetBndr to represent non-top-level type-let binders

IfaceLetBndr isn't fit to represent type-let binders, as it includes a
bunch of vacuous flags for Ids only.
Instead of putting squares in circles, I added a new constructor for type binders.

The downside is that it breaks existing iface files, so since we can't bootstrap
yet so we have to bootstrap a cherry-picked branch and then checkout again to build
with --freeze1.

To avoid similar issues in the future, IfaceTyVarInfoItem serialises with a tag
despite there being only one constructor for now.

- - - - -
49493a15 by Joseph Fourment at 2024-12-17T10:15:44+00:00
dmd-anal: prefix unused variable with _ to avoid warning

- - - - -
4b29943b by Joseph Fourment at 2024-12-17T10:15:44+00:00
type: inline unfoldView in sORTKind_maybe

- - - - -
effe2574 by Joseph Fourment at 2024-12-17T10:15:44+00:00
tidy: deal with type-lets

- - - - -
d05f4cb0 by Joseph Fourment at 2024-12-17T10:15:44+00:00
notes: add Note [Type and coercion lets]

- - - - -
ed64d817 by Joseph Fourment at 2024-12-17T10:15:44+00:00
notes: update Note [Comparing nullary type synonyms] to account for type variables

While updating backlinks, I noticed the optimisation for type variables
could be performed in more places.

- - - - -
e8de3a0b by Joseph Fourment at 2024-12-17T10:15:44+00:00
simplifier: inline single-occurring type-lets

- - - - -
66797366 by Joseph Fourment at 2024-12-17T10:15:44+00:00
cleanup: remove NOINLINE on tyVarOccInfo

- - - - -
40a42566 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Wibbles

- - - - -
f8864d41 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Wibbles

- - - - -
15435281 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Progress

- - - - -
b51aece5 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Progress

- - - - -
0eb2f585 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
More progress

- - - - -
3ebd0189 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Progress

...doesn't compile though

- - - - -
7ee91976 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Mostly working now

- - - - -
320c114d by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Aggressively create type-lets

- - - - -
b1935c2c by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
more progress

- - - - -
095a162a by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
More progress

- - - - -
3e691b7a by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Temp debug printing

- - - - -
2d5ca13c by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Remove bogus assert

- - - - -
5e077c38 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Fix anoher couple of bugs

in SimpleOpt and exprIsTrivial

- - - - -
1c3341d7 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Improve zonking of foreign decls to avoid TcTyVars escaping

- - - - -
bb1de634 by Simon Peyton Jones at 2024-12-17T10:15:44+00:00
Wibbles

- - - - -
34e2b65f by Simon Peyton Jones at 2024-12-17T10:15:45+00:00
Some small wibbles

- - - - -
b8b48fce by Simon Peyton Jones at 2024-12-17T10:15:45+00:00
Improvements

- - - - -
2c57c570 by Simon Peyton Jones at 2024-12-17T10:15:45+00:00
Rmmove trace

- - - - -
fb17f57d by Simon Peyton Jones at 2024-12-17T12:13:11+00:00
Wibbles

- - - - -


14 changed files:

- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Axiom.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CSE.hs
- compiler/GHC/Core/Opt/CallArity.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/SetLevels.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/63954e4cbca1ee47fa2290cf8406588e6bfee045...fb17f57d4a93b837f29734c33dc0d7ac77c71e6c

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/63954e4cbca1ee47fa2290cf8406588e6bfee045...fb17f57d4a93b837f29734c33dc0d7ac77c71e6c
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/20241217/e076581a/attachment-0001.html>


More information about the ghc-commits mailing list