[Git][ghc/ghc][wip/amg/dcoercion] 11 commits: rts: Ensure non-moving gc is not running when pausing

sheaf (@sheaf) gitlab at gitlab.haskell.org
Sat May 13 14:04:58 UTC 2023 


sheaf pushed to branch wip/amg/dcoercion at Glasgow Haskell Compiler / GHC


Commits:
aa84cff4 by Teo Camarasu at 2023-05-12T19:27:23-04:00
rts: Ensure non-moving gc is not running when pausing

- - - - -
5ad776ab by Teo Camarasu at 2023-05-12T19:27:23-04:00
rts: Teach listAllBlocks about nonmoving heap

List all blocks on the non-moving heap.

Resolves #22627

- - - - -
d683b2e5 by Krzysztof Gogolewski at 2023-05-12T19:28:00-04:00
Fix coercion optimisation for SelCo (#23362)

setNominalRole_maybe is supposed to output a nominal coercion.
In the SelCo case, it was not updating the stored role to Nominal,
causing #23362.

- - - - -
59aa4676 by Alexis King at 2023-05-12T19:28:47-04:00
hadrian: Fix linker script flag for MergeObjects builder

This fixes what appears to have been a typo in !9530. The `-t` flag just
enables tracing on all versions of `ld` I’ve looked at, while `-T` is
used to specify a linker script. It seems that this worked anyway for
some reason on some `ld` implementations (perhaps because they
automatically detect linker scripts), but the missing `-T` argument
causes `gold` to complain.

- - - - -
4bf9fa0f by Adam Gundry at 2023-05-12T23:49:49-04:00
Less coercion optimization for non-newtype axioms

See Note [Push transitivity inside newtype axioms only] for an explanation
of the change here.  This change substantially improves the performance of
coercion optimization for programs involving transitive type family reductions.

-------------------------
Metric Decrease:
    CoOpt_Singletons
    LargeRecord
    T12227
    T12545
    T13386
    T15703
    T5030
    T8095
-------------------------

- - - - -
dc0c9574 by Adam Gundry at 2023-05-12T23:49:49-04:00
Move checkAxInstCo to GHC.Core.Lint

A consequence of the previous change is that checkAxInstCo is no longer
called during coercion optimization, so it can be moved back where it belongs.

Also includes some edits to Note [Conflict checking with AxiomInstCo] as
suggested by @simonpj.

- - - - -
8b9b7dbc by Simon Peyton Jones at 2023-05-12T23:50:25-04:00
Use the eager unifier in the constraint solver

This patch continues the refactoring of the constraint solver
described in #23070.

The Big Deal in this patch is to call the regular, eager unifier from the
constraint solver, when we want to create new equalities. This
replaces the existing, unifyWanted which amounted to
yet-another-unifier, so it reduces duplication of a rather subtle
piece of technology. See

  * Note [The eager unifier] in GHC.Tc.Utils.Unify
  * GHC.Tc.Solver.Monad.wrapUnifierTcS

I did lots of other refactoring along the way

* I simplified the treatment of right hand sides that contain CoercionHoles.
  Now, a constraint that contains a hetero-kind CoercionHole is non-canonical,
  and cannot be used for rewriting or unification alike.  This required me
  to add the ch_hertero_kind flag to CoercionHole, with consequent knock-on
  effects. See wrinkle (2) of `Note [Equalities with incompatible kinds]` in
  GHC.Tc.Solver.Equality.

* I refactored the StopOrContinue type to add StartAgain, so that after a
  fundep improvement (for example) we can simply start the pipeline again.

* I got rid of the unpleasant (and inefficient) rewriterSetFromType/Co functions.
  With Richard I concluded that they are never needed.

* I discovered Wrinkle (W1) in Note [Wanteds rewrite Wanteds] in
  GHC.Tc.Types.Constraint, and therefore now prioritise non-rewritten equalities.

Quite a few error messages change, I think always for the better.

Compiler runtime stays about the same, with one outlier: a 17% improvement in T17836

Metric Decrease:
    T17836
    T18223

- - - - -
5cad28e7 by Bartłomiej Cieślar at 2023-05-12T23:51:06-04:00
Cleanup of dynflags override in export renaming
The deprecation warnings are normally emitted whenever the name's GRE is being looked up, which calls the GHC.Rename.Env.addUsedGRE function. We do not want those warnings to be emitted when renaming export lists, so they are artificially turned off by removing all warning categories from DynFlags at the beginning of GHC.Tc.Gen.Export.rnExports. This commit removes that dependency by unifying the function used for GRE lookup in lookup_ie to lookupGreAvailRn and disabling the call to addUsedGRE in said function (the warnings are also disabled in a call to lookupSubBndrOcc_helper in lookupChildrenExport), as per #17957. This commit also changes the setting for whether to warn about deprecated names in addUsedGREs to be an explicit enum instead of a boolean.

- - - - -
efc61741 by Adam Gundry at 2023-05-13T14:59:47+02:00
Directed coercions

We introduce a slimmer version of coercions, directed coercions,
which store fewer types within them. This more compact representation
considerably speeds up programs which involve many type family
reductions, as the coercion size no longer grows quadratically in
the number of reduction steps.

- - - - -
fbb0665a by sheaf at 2023-05-13T15:58:48+02:00
WIP: remove LHS type in Reduction

- - - - -
b7db69ce by sheaf at 2023-05-13T15:59:10+02:00
Fix bad multiplicity role in tyConAppFunCo_maybe

The function tyConAppFunCo_maybe produces a multiplicity coercion
for the multiplicity argument of the function arrow, except that
it could be at the wrong role if asked to produce a representational
coercion. We fix this by using the 'funRole' function, which computes
the right roles for arguments to the function arrow TyCon.

Fixes #23386

- - - - -


6 changed files:

- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion.hs-boot
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/FamInstEnv.hs
- + compiler/GHC/Core/FamInstEnv.hs-boot


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5e07c825ebf2028273066e8201de4ffec97ab806...b7db69ceb32dbb4161193e9e558b8281e0873cfb

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5e07c825ebf2028273066e8201de4ffec97ab806...b7db69ceb32dbb4161193e9e558b8281e0873cfb
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/20230513/2802d961/attachment.html>

More information about the ghc-commits mailing list