[Git][ghc/ghc][wip/T20749] 6 commits: Take care when simplifying unfoldings

Sebastian Graf (@sgraf812) gitlab at gitlab.haskell.org
Sat Dec 9 16:43:52 UTC 2023



Sebastian Graf pushed to branch wip/T20749 at Glasgow Haskell Compiler / GHC


Commits:
d8baa1bd by Simon Peyton Jones at 2023-12-08T15:40:37+00:00
Take care when simplifying unfoldings

This MR fixes a very subtle bug exposed by #24242.

See Note [Environment for simplLetUnfolding].

I also updated a bunch of Notes on shadowing

- - - - -
03ca551d by Simon Peyton Jones at 2023-12-08T15:54:50-05:00
Comments only in FloatIn

Relevant to #3458

- - - - -
50c78779 by Simon Peyton Jones at 2023-12-08T15:54:50-05:00
Comments only in SpecConstr

- - - - -
9431e195 by Simon Peyton Jones at 2023-12-08T15:54:50-05:00
Add test for #22238

- - - - -
7e06ea59 by Sebastian Graf at 2023-12-09T17:39:54+01:00
CorePrep: Attach evaldUnfolding to floats to detect more values

See `Note [Pin evaluatedness on floats]`.

- - - - -
12b80370 by Sebastian Graf at 2023-12-09T17:40:27+01: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:

  * `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).

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

- - - - -


30 changed files:

- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CSE.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Stg/CSE.hs
- compiler/GHC/Stg/InferTags.hs
- compiler/GHC/Stg/InferTags/Rewrite.hs
- compiler/GHC/Tc/Instance/Class.hs
- compiler/GHC/Tc/TyCl/Build.hs
- compiler/GHC/Types/Demand.hs
- compiler/GHC/Types/Id/Info.hs
- compiler/GHC/Types/Id/Make.hs
- compiler/GHC/Utils/Misc.hs
- testsuite/tests/ghci/should_run/T21052.stdout
- + testsuite/tests/quantified-constraints/T22238.hs
- testsuite/tests/quantified-constraints/all.T
- testsuite/tests/simplCore/should_compile/T23083.stderr


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2fb45f126fdcdfd1e715d998d194254ac1148137...12b80370a82b4191558aef01eb7203035193c0a2

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2fb45f126fdcdfd1e715d998d194254ac1148137...12b80370a82b4191558aef01eb7203035193c0a2
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/20231209/5818c977/attachment.html>


More information about the ghc-commits mailing list