[Git][ghc/ghc][wip/T18223] 7 commits: Add a test for #18397

Simon Peyton Jones gitlab at gitlab.haskell.org
Tue Aug 25 23:04:56 UTC 2020 


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


Commits:
a77b9ec2 by Krzysztof Gogolewski at 2020-08-24T10:04:20-04:00
Add a test for #18397

The bug was fixed by !3421.

- - - - -
05550a5a by Sylvain Henry at 2020-08-24T10:04:59-04:00
Avoid roundtrip through SDoc

As found by @monoidal on https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3885#note_295126

- - - - -
0a1ecc5f by Ben Gamari at 2020-08-25T07:37:05-04:00
SysTools.Process: Handle exceptions in readCreateProcessWithExitCode'

In #18069 we are observing MVar deadlocks from somewhere in ghc.exe.
This use of MVar stood out as being one of the more likely culprits.
Here we make sure that it is exception-safe.

- - - - -
db8793ad by Richard Eisenberg at 2020-08-25T07:37:40-04:00
Use tcView, not coreView, in the pure unifier.

Addresses a lingering point within #11715.

- - - - -
fb77207a by Simon Peyton Jones at 2020-08-25T07:38:16-04:00
Use LIdP rather than (XRec p (IdP p))

This patch mainly just replaces use of
    XRec p (IdP p)
with
    LIdP p

One slightly more significant change is to parameterise
HsPatSynDetails over the pass rather than the argument type,
so that it's uniform with HsConDeclDetails and HsConPatDetails.

I also got rid of the dead code GHC.Hs.type.conDetailsArgs

But this is all just minor refactoring. No change in functionality.

- - - - -
8426a136 by Krzysztof Gogolewski at 2020-08-25T07:38:54-04:00
Add a test for #18585

- - - - -
6362994e by Simon Peyton Jones at 2020-08-26T00:04:07+01:00
Better eta-expansion (again) and don't specilise DFuns

This patch fixes #18223, which made GHC generate an exponential
amount of code.  There are three quite separate changes in here

1.  Re-engineer eta-expansion (again).  The eta-expander was
    generating lots of intermediate stuff, which could be optimised
    away, but which choked the simplifier meanwhile.  Relatively
    easy to kill it off at source.

    See Note [The EtaInfo mechanism] in GHC.Core.Opt.Arity.
    The main new thing is the use of pushCoArg in getArg_maybe.

2.  Stop Specialise specalising DFuns.  This is the cause of a huge
    (and utterly unnecessary) blowup in program size in #18223.
    See Note [Do not specialise DFuns] in GHC.Core.Opt.Specialise.

    I also refactored the Specialise monad a bit... it was silly,
    because it passed on unchanging values as if they were mutable
    state.

3.  Do an extra Simplifer run, after SpecConstra and before
    late-Specialise.  I found (investigating perf/compiler/T16473)
    that failing to do this was crippling *both* SpecConstr *and*
    Specialise.  See Note [Simplify after SpecConstr] in
    GHC.Core.Opt.Pipeline.

    This change does mean an extra run of the Simplifier, but only
    with -O2, and I think that's acceptable.

    T16473 allocates *three* times less with this change.  (I changed
    it to check runtime rather than compile time.)

Some smaller consequences

* I moved pushCoercion, pushCoArg and friends from SimpleOpt
  to Arity, because it was needed by the new etaInfoApp.

  And pushCoValArg now returns a MCoercion rather than Coercion for
  the argument Coercion.

* A minor, incidental improvement to Core pretty-printing

This does fix #18223, (which was otherwise uncompilable. Hooray.  But
there is still a big intermediate because there are some very deeply
nested types in that program.

Modest reductions in compile-time allocation on a couple of benchmarks
  12425              -2.5%
  13253              -10.4%
  MultiLayerModules  -0.6%

Metric increase with -O2, due to extra simplifier run
    T9233     +5.8%
    T12227    +1.7%

Metric Increase
    T9233
    T12227

- - - - -


30 changed files:

- compiler/GHC/CmmToAsm/Dwarf.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Ppr.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Match/Constructor.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Utils.hs
- compiler/GHC/Parser.y
- compiler/GHC/SysTools/Process.hs
- compiler/GHC/Tc/TyCl/PatSyn.hs
- compiler/GHC/Tc/Utils/Zonk.hs
- + testsuite/tests/codeGen/should_compile/T18397.hs
- testsuite/tests/codeGen/should_compile/all.T
- testsuite/tests/perf/compiler/Makefile
- testsuite/tests/perf/compiler/T16473.stdout


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e3c76de3eb2a09d78ebc14cc5c11b667b69c5807...6362994e6e6de297f4b8704a6386fd396312bd85

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e3c76de3eb2a09d78ebc14cc5c11b667b69c5807...6362994e6e6de297f4b8704a6386fd396312bd85
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/20200825/be276ca6/attachment.html>

More information about the ghc-commits mailing list