[Git][ghc/ghc][wip/az/epa-remove-addepann-8] 17 commits: Improve heap overflow exception message (#25198)

Alan Zimmerman (@alanz) gitlab at gitlab.haskell.org
Sat Oct 26 11:22:48 UTC 2024



Alan Zimmerman pushed to branch wip/az/epa-remove-addepann-8 at Glasgow Haskell Compiler / GHC


Commits:
6ab8d751 by ignatiusm at 2024-10-24T01:23:35-04:00
Improve heap overflow exception message (#25198)

Catch heap overflow exceptions and suggest using `+RTS -M<size>`.

Fix #25198

- - - - -
b3f7fb80 by Rodrigo Mesquita at 2024-10-24T01:24:12-04:00
determinism: Interface re-export list det

In 'DocStructureItem' we want to make sure the 'Avails' are sorted, for
interface file determinism. This commit introduces 'DetOrdAvails', a
newtype that should only be constructed by sorting Avails with
'sortAvails' unless the avails are known to be deterministically
ordered. This newtype is used by 'DocStructureItem' where 'Avails' was
previously used to ensure the list of avails is deterministically sorted
by construction.

Note: Even though we order the constructors and avails in the interface
file, the order of constructors in the haddock output is still
determined from the order of declaration in the source. This was also
true before, when the list of constructors in the interface file <docs>
section was non-deterministic. Some haddock tests such as
"ConstructorArgs" observe this (check the order of constructors in
out/ConstructorArgs.html vs src/ConstructorArgs.hs vs its interface file)

The updated tests are caused by haddock corners where the order in the
source is not preserved (and was non-deterministic before this PR):
    * Module header in the latex backend
    * Re-export of pattern synonyms associated to a datatype (#25342)

Fixes #25304

- - - - -
e39c8c99 by Rodrigo Mesquita at 2024-10-24T01:24:12-04:00
Revert "ci: Allow abi-test to fail."

After #25304, the abi-test with interface and object determinism
succeeds.

This reverts commit 7b37afc9f3e79559055488998ee73187886a0e00.

- - - - -
7b1b0c6d by Alan Zimmerman at 2024-10-24T13:07:02-04:00
EPA: reduce [AddEpann] in AnnList

Remove it from the `al_rest` field, and make `AnnList` parameterized
on a type to be used in `al_rest`, for the various use cases.

- - - - -
4a00731e by Rodrigo Mesquita at 2024-10-24T13:07:38-04:00
Fix -fobject-determinism flag definition

The flag should be defined as an fflag to make sure the
-fno-object-determinism flag is also an available option.

Fixes #25397

- - - - -
55e4b9f2 by Sebastian Graf at 2024-10-25T07:01:54-04:00
CorePrep: Attach evaldUnfolding to floats to detect more values

See `Note [Pin evaluatedness on floats]`.

- - - - -
9f57c96d by Sebastian Graf at 2024-10-25T07:01:54-04:00
Make DataCon workers strict in strict fields (#20749)

This patch tweaks `exprIsConApp_maybe`, `exprIsHNF` and friends, and Demand
Analysis so that they exploit and maintain strictness of DataCon workers. See
`Note [Strict fields in Core]` for details.

Very little needed to change, and it puts field seq insertion done by Tag
Inference into a new perspective: That of *implementing* strict field semantics.
Before Tag Inference, DataCon workers are strict. Afterwards they are
effectively lazy and field seqs happen around use sites. History has shown
that there is no other way to guarantee taggedness and thus the STG Strict Field
Invariant.

Knock-on changes:

  * I reworked the whole narrative around "Tag inference".
    It's now called "EPT enforcement" and I recycyled the different overview
    Notes into `Note [EPT enforcement]`.

  * `exprIsHNF` previously used `exprOkForSpeculation` on unlifted arguments
    instead of recursing into `exprIsHNF`. That regressed the termination
    analysis in CPR analysis (which simply calls out to `exprIsHNF`), so I made
    it call `exprOkForSpeculation`, too.

  * There's a small regression in Demand Analysis, visible in the changed test
    output of T16859: Previously, a field seq on a variable would give that
    variable a "used exactly once" demand, now it's "used at least once",
    because `dmdTransformDataConSig` accounts for future uses of the field
    that actually all go through the case binder (and hence won't re-enter the
    potential thunk). The difference should hardly be observable.

  * The Simplifier's fast path for data constructors only applies to lazy
    data constructors now. I observed regressions involving Data.Binary.Put's
    `Pair` data type.

  * Unfortunately, T21392 does no longer reproduce after this patch, so I marked
    it as "not broken" in order to track whether we regress again in the future.

Fixes #20749, the satisfying conclusion of an annoying saga (cf. the ideas
in #21497 and #22475).

Compiler perf generally improves, sometimes drastically:

                                                     Baseline
                                 Test    Metric          value      New value Change
--------------------------------------------------------------------------------
             ManyConstructors(normal) ghc/alloc  3,629,760,116  3,711,852,800  +2.3%  BAD
  MultiLayerModulesTH_OneShot(normal) ghc/alloc  2,502,735,440  2,565,282,888  +2.5%  BAD
                       T12707(normal) ghc/alloc    804,399,798    791,807,320  -1.6% GOOD
                       T17516(normal) ghc/alloc    964,987,744  1,008,383,520  +4.5%
                       T18140(normal) ghc/alloc     75,381,152     49,860,560 -33.9% GOOD
                      T18698b(normal) ghc/alloc    232,614,457    184,262,736 -20.8% GOOD
                       T18923(normal) ghc/alloc     62,002,368     58,301,408  -6.0% GOOD
                       T20049(normal) ghc/alloc     75,719,168     70,494,368  -6.9% GOOD
                        T3294(normal) ghc/alloc  1,237,925,833  1,157,638,992  -6.5% GOOD
                        T9233(normal) ghc/alloc    686,490,105    635,166,688  -7.5% GOOD

                            geo. mean                                          -0.7%
                            minimum                                           -33.9%
                            maximum                                            +4.5%

I looked at T17516. It seems we do a few more simplifier iterations and end up
with a larger program. It seems that some things inline more, while other things
inline less. I don't see low-hanging fruit.

I also looked at MultiLayerModulesTH_OneShot. It appears we generate a strange
join point in the `getUnique` method of `Uniquable GHC.Unit.Types.Module` that
should better call-site inline, but does not. Perhaps with !11492.

NoFib does not seem affected much either:

+-------------------------------++--+------------+-----------+---------------+-----------+
|                               ||  |      base/ | std. err. | T20749/ (rel) | std. err. |
+===============================++==+============+===========+===============+===========+
|           spectral/last-piece ||  |    7.263e8 |      0.0% |        +0.62% |      0.0% |
+===============================++==+============+===========+===============+===========+
|                     geom mean ||  |     +0.00% |           |               |           |
+-------------------------------++--+------------+-----------+---------------+-----------+

I had a look at last-piece. Nothing changes in stg-final, but there is a bit
of ... movement around Data.Map.insert's use of GHC.Exts.lazy that is gone in
stg-final.

Co-Authored-By: Jaro Reinders <jaro.reinders at gmail.com>

Metric Decrease:
    T12707
    T18140
    T18698b
    T18923
    T19695
    T20049
    T3294
    T9233
    T21839c
Metric Increase:
    ManyConstructors
    MultiLayerModulesTH_OneShot

- - - - -
0225249a by Simon Peyton Jones at 2024-10-25T07:02:32-04:00
Some renaming

This is a pure refactor, tidying up some inconsistent naming:

   isEqPred          -->  isEqClassPred
   isEqPrimPred      -->  isEqPred
   isReprEqPrimPred  -->  isReprEqPred
   mkPrimEqPred      -->  mkNomEqPred
   mkReprPrimEqPred  -->  mkReprEqPred
   mkPrimEqPredRold  -->  mkEqPredRole

Plus I moved mkNomEqPred, mkReprEqPred, mkEqPredRolek
  from GHC.Core.Coercion to GHC.Core.Predicate
where they belong.  That means that Coercion imports Predicate
rather than vice versa -- better.

- - - - -
15a3456b by Ryan Hendrickson at 2024-10-25T07:02:32-04:00
compiler: Fix deriving with method constraints

See Note [Inferred contexts from method constraints]

Co-authored-by: Simon Peyton Jones <simon.peytonjones at gmail.com>

- - - - -
0dd3dd6f by Alan Zimmerman at 2024-10-26T10:34:09+01:00
EPA: Remove [AddEpAnn] from HYPHEN in Parser.y

The return value is never used, as it is part of the backpack
configuration parsing.

- - - - -
1905e004 by Alan Zimmerman at 2024-10-26T10:34:09+01:00
EPA: Remove last [AddEpAnn] usages

Remove residual usage in GHC. It is still used
- In haddock TTG extension point definitions (to be removed)
- Some check-exact residual, to be removed
- Comments around DisambECP in PostProcess

- - - - -
9b77f34e by Alan Zimmerman at 2024-10-26T10:34:09+01:00
EPA: Clean up [AddEpAnn] from check-exact

There is one left, to be cleaned up when we remove AddEpann itself

- - - - -
eb82fcfa by Alan Zimmerman at 2024-10-26T10:34:09+01:00
EPA: Remove [AddEpAnn] from haddock

The TTG extension points need a value, it is not critical what that
value is, in most cases.

- - - - -
2686f890 by Alan Zimmerman at 2024-10-26T10:34:09+01:00
EPA: Remove AddEpAnn from HsRuleAnn

- - - - -
fc969d40 by Alan Zimmerman at 2024-10-26T10:34:09+01:00
EPA: Remove AddEpAnn from HsCmdArrApp

- - - - -
7c7f8c62 by Alan Zimmerman at 2024-10-26T10:34:09+01:00
EPA: Remove AddEpAnn from AnnList

- - - - -
4e4d652d by Alan Zimmerman at 2024-10-26T12:22:08+01:00
EPA: Remove AddEpAnn from GrhsAnn

This is the last actual use

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Predicate.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Doc.hs
- compiler/GHC/Hs/Dump.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/ImpExp.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/996503fb908d98b8021fd7d57aced092efd21d15...4e4d652d849b2b58b4c804983a7c3fbd3e688ce2

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/996503fb908d98b8021fd7d57aced092efd21d15...4e4d652d849b2b58b4c804983a7c3fbd3e688ce2
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/20241026/c1a33559/attachment-0001.html>


More information about the ghc-commits mailing list