[Git][ghc/ghc][wip/9.2.6-backports] 29 commits: Fix #22425 - Broken eta-expansion over expensive work.

Zubin (@wz1000) gitlab at gitlab.haskell.org
Tue Feb 7 13:18:24 UTC 2023



Zubin pushed to branch wip/9.2.6-backports at Glasgow Haskell Compiler / GHC


Commits:
6eaf0d3d by Andreas Klebinger at 2023-02-07T18:47:08+05:30
Fix #22425 - Broken eta-expansion over expensive work.

This is the 9.2 backport of !9357

Through a mistake in the latest backport we started eta-expanding over
expensive work by mistake. E.g. over <expensive> in code like:

  case x of
    A -> id
    B -> <expensive>

We fix this by only eta-expanding over <expensive> if all other branches
are headed by an oneShot lambda.

In the long story of broken eta-expansion on 9.2/9.4 this is hopefully
the last chapter.

-------------------------
Metric Increase:
    CoOpt_Read
    T1969
    parsing001
    TcPlugin_RewritePerf
    LargeRecord
-------------------------

(cherry picked from commit ce608479c7f40a9899a6448379d05861bee77b41)

- - - - -
fed9cff1 by Simon Peyton Jones at 2023-02-07T18:47:08+05:30
Add a missing varToCoreExpr in etaBodyForJoinPoint

This subtle bug showed up when compiling a library with 9.4.
See #22491.  The bug is present in master, but it is hard to
trigger; the new regression test T22491 fails in 9.4.

The fix was easy: just add a missing varToCoreExpr in
etaBodyForJoinPoint.

The fix is definitely right though!

I also did some other minor refatoring:
* Moved the preInlineUnconditionally test in simplExprF1 to
  before the call to joinPointBinding_maybe, to avoid fruitless
  eta-expansion.
* Added a boolean from_lam flag to simplNonRecE, to avoid two
  fruitless tests, and commented it a bit better.

These refactorings seem to save 0.1% on compile-time allocation in
perf/compiler; with a max saving of 1.4% in T9961

Metric Decrease:
    T9961

(cherry picked from commit afc2540daf6ca6baa09ab147b792da08d66d878c)

- - - - -
ce180d2f by Matthew Pickering at 2023-02-07T18:47:08+05:30
Typeable: Fix module locations of some definitions in GHC.Types

There was some confusion in Data.Typeable about which module certain
wired-in things were defined in. Just because something is wired-in
doesn't mean it comes from GHC.Prim, in particular things like LiftedRep
and RuntimeRep are defined in GHC.Types and that's the end of the story.

Things like Int#, Float# etc are defined in GHC.Prim as they have no
Haskell definition site at all so we need to generate type
representations for them (which live in GHC.Types).

Fixes #22510

(cherry picked from commit 1d3a8b8ec98e6eedf8943e19780ec374c2491e7f)

- - - - -
aac592f3 by Andreas Klebinger at 2023-02-07T18:47:08+05:30
Fix LitRubbish being applied to values.

This fixes #19824

This is the 9.2 backport of commit 52ce8590ab18fb1fc99bd9aa24c016f786d7f7d1

(cherry picked from commit 2e02959ab40f2b67499aaffc29ee1dc9f0d48158)

- - - - -
8aaf86f8 by Simon Peyton Jones at 2023-02-07T18:47:08+05:30
Fix unifier bug: failing to decompose over-saturated type family

This simple patch fixes #22647

(cherry picked from commit 317f45c154f6fe25d50ef2f3febcc5883ff1b1ca)

- - - - -
03da82af by Sebastian Graf at 2023-02-07T18:47:08+05:30
Handle shadowing in DmdAnal (#22718)

Previously, when we had a shadowing situation like
```hs
f x = ... -- demand signature <1L><1L>

main = ... \f -> f 1 ...
```
we'd happily use the shadowed demand signature at the call site inside the
lambda. Of course, that's wrong and solution is simply to remove the demand
signature from the `AnalEnv` when we enter the lambda.
This patch does so for all binding constructs Core.

In #22718 the issue was caused by LetUp not shadowing away the existing demand
signature for the let binder in the let body. The resulting absent error is
fickle to reproduce; hence no reproduction test case. #17478 would help.

Fixes #22718.

It appears that TcPlugin_Rewrite regresses by ~40% on Darwin. It is likely that
DmdAnal was exploiting ill-scoped analysis results.

Metric increase ['bytes allocated'] (test_env=x86_64-darwin-validate):
    TcPlugin_Rewrite

(cherry picked from commit e3fff7512bbf989386faaa1dccafdad1deabde84)

- - - - -
7e47d0f5 by Zubin Duggal at 2023-02-07T18:47:09+05:30
Bump bytestring submodule to 0.11.4.0

- - - - -
d130b39f by Andreas Klebinger at 2023-02-07T18:47:09+05:30
Only gc sparks locally when we can ensure marking is done.

When performing GC without work stealing there was no guarantee that
spark pruning was happening after marking of the sparks. This could
cause us to GC live sparks under certain circumstances.

Fixes #22528.

(cherry picked from commit a1491c8791c57a64d94bc08d639d585815c8d4e2)

- - - - -
5b2af591 by Ian-Woo Kim at 2023-02-07T18:47:09+05:30
Truncate eventlog event for large payload (#20221)

RTS eventlog events for postCapsetVecEvent are truncated if payload
is larger than EVENT_PAYLOAD_SIZE_MAX
Previously, postCapsetVecEvent records eventlog event with payload
of variable size larger than EVENT_PAYLOAD_SIZE_MAX (2^16) without
any validation, resulting in corrupted data.
For example, this happens when a Haskell binary is invoked with very
long command line arguments exceeding 2^16 bytes (see #20221).
Now we check the size of accumulated payload messages incrementally,
and truncate the message just before the payload size exceeds
EVENT_PAYLOAD_SIZE_MAX. RTS will warn the user with a message showing
how many arguments are truncated.

(cherry picked from commit 2057c77d08cb8422857d182a3691f98dccd0c7d6)

- - - - -
ec04fbed by Simon Peyton Jones at 2023-02-07T18:47:09+05:30
Make FloatIn robust to shadowing

This MR fixes #22622. See the new
  Note [Shadowing and name capture]

I did a bit of refactoring in sepBindsByDropPoint too.

The bug doesn't manifest in HEAD, but it did show up in 9.4,
so we should backport this patch to 9.4

(cherry picked from commit 6206cb9287f3f6e70c669660a646a65274870d2b)

- - - - -
a225dbb1 by Ben Gamari at 2023-02-07T18:47:09+05:30
Bump ghc-tarballs to fix #22497

It turns out that gmp 6.2.1 uses the platform-reserved `x18` register on
AArch64/Darwin. This was fixed in upstream changeset 18164:5f32dbc41afc,
which was merged in 2020. Here I backport this patch although I do hope
that a new release is forthcoming soon.

Bumps gmp-tarballs submodule.

Fixes #22497.

(cherry picked from commit f891a442046d8a5ebf4d4777847880ce06752b18)

- - - - -
cf2da09a by Ben Gamari at 2023-02-07T18:47:09+05:30
Bump gmp-tarballs submodule

This backports the upstream fix for CVE-2021-43618, fixing #22789.

(cherry picked from commit b13c6ea5d4b64841164f8cc58d6c6f3de390f2ed)

- - - - -
09224b90 by Oleg Grenrus at 2023-02-07T18:47:09+05:30
Fix #22728: Not all diagnostics in safe check are fatal

Also add tests for the issue and -Winferred-safe-imports in general

(cherry picked from commit 1b812b6973a25cb1962e2fc543d2c4ed3cf31f3c)

- - - - -
27f154f9 by Zubin Duggal at 2023-02-07T18:47:09+05:30
Document #22255 and #22468 in bugs.rst

- - - - -
c63a3e25 by Simon Peyton Jones at 2023-02-07T18:47:09+05:30
Fix an assertion check in addToEqualCtList

The old assertion saw that a constraint ct could rewrite itself
(of course it can) and complained (stupid).

Fixes #22645

(cherry picked from commit 3d55d8ab51ece43c51055c43c9e7aba77cce46c0)

- - - - -
eadbbbcf by Simon Peyton Jones at 2023-02-07T18:47:09+05:30
Fix shadowing lacuna in OccurAnal

Issue #22623 demonstrated another lacuna in the implementation
of wrinkle (BS3) in Note [The binder-swap substitution] in
the occurrence analyser.

I was failing to add TyVar lambda binders using
addInScope/addOneInScope and that led to a totally bogus binder-swap
transformation.

Very easy to fix.

(cherry picked from commit e193e53790dd5886feea3cf4c9c17625d188291b)

- - - - -
a090f5c3 by Sebastian Graf at 2023-02-07T18:47:09+05:30
DmdAnal: Don't panic in addCaseBndrDmd (#22039)

Rather conservatively return Top.
See Note [Untyped demand on case-alternative binders].

I also factored `addCaseBndrDmd` into two separate functions `scrutSubDmd` and
`fieldBndrDmds`.

Fixes #22039.

(cherry picked from commit d2be80fd9b222963e8dd09a30f78c106e00da7f9)

- - - - -
52e579b6 by Matthew Pickering at 2023-02-07T18:47:09+05:30
ApplicativeDo: Set pattern location before running exhaustiveness checker

This improves the error messages of the exhaustiveness checker when
checking statements which have been moved around with ApplicativeDo.

Before:

Test.hs:2:3: warning: [GHC-62161] [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘Maybe ()’ not matched: Nothing
  |
2 |   let x = ()
  |   ^^^^^^^^^^

After:

Test.hs:4:3: warning: [GHC-62161] [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘Maybe ()’ not matched: Nothing
  |
4 |   ~(Just res1) <- seq x (pure $ Nothing @())
  |

Fixes #22483

(cherry picked from commit 74c767df770766d8d52e87b9ff7da10f94620a91)
(cherry picked from commit 51c6051bcc405bc1dbddd450ade949acd70db6b8)

- - - - -
96ab827a by Andreas Klebinger at 2023-02-07T18:47:09+05:30
ghc-the-library: Retain cafs in both static in dynamic builds.

We use keepCAFsForGHCi.c to force -fkeep-cafs behaviour by using a
__attribute__((constructor)) function.

This broke for static builds where the linker discarded the object file
since it was not reverenced from any exported code. We fix this by
asserting that the flag is enabled using a function in the same module
as the constructor. Which causes the object file to be retained by the
linker, which in turn causes the constructor the be run in static builds.

This changes nothing for dynamic builds using the ghc library. But causes
static to also retain CAFs (as we expect them to).

Fixes #22417.

-------------------------
Metric Decrease:
    T21839r
-------------------------

(cherry picked from commit 08ba87200ff068aa37cac082e61ee7e2d534daf5)

- - - - -
898ca9c6 by Matthew Pickering at 2023-02-07T18:47:09+05:30
T10955: Set DYLD_LIBRARY_PATH for darwin

The correct path to direct the dynamic linker on darwin is
DYLD_LIBRARY_PATH rather than LD_LIBRARY_PATH. On recent versions of OSX
using LD_LIBRARY_PATH seems to have stopped working.

For more reading see:

https://stackoverflow.com/questions/3146274/is-it-ok-to-use-dyld-library-path-on-mac-os-x-and-whats-the-dynamic-library-s
(cherry picked from commit a960ca817d6ad0109ea6edda50da3902cc538e86)

- - - - -
8e0c0da5 by Matthew Pickering at 2023-02-07T18:47:09+05:30
Skip T18623 on darwin (to add to the long list of OSs)

On recent versions of OSX, running `ulimit -v` results in

```
ulimit: setrlimit failed: invalid argument
```

Time is too short to work out what random stuff Apple has been doing
with ulimit, so just skip the test like we do for other platforms.

(cherry picked from commit 734847108420cf826a807c30ad54651659cf3a08)

- - - - -
8ef4fec1 by Matthew Pickering at 2023-02-07T18:47:09+05:30
Pass -Wl,-no_fixup_chains to ld64 when appropiate

Recent versions of MacOS use a version of ld where `-fixup_chains` is on by default.
This is incompatible with our usage of `-undefined dynamic_lookup`. Therefore we
explicitly disable `fixup-chains` by passing `-no_fixup_chains` to the linker on
darwin. This results in a warning of the form:

ld: warning: -undefined dynamic_lookup may not work with chained fixups

The manual explains the incompatible nature of these two flags:

     -undefined treatment
             Specifies how undefined symbols are to be treated. Options are: error, warning,
             suppress, or dynamic_lookup.  The default is error. Note: dynamic_lookup that
             depends on lazy binding will not work with chained fixups.

A relevant ticket is #22429

Here are also a few other links which are relevant to the issue:

Official comment: https://developer.apple.com/forums/thread/719961

More relevant links:

https://openradar.appspot.com/radar?id=5536824084660224

https://github.com/python/cpython/issues/97524

Note in release notes: https://developer.apple.com/documentation/xcode-release-notes/xcode-13-releas    e-notes

(cherry picked from commit 8c0ea25fb4a27d4729aabf73f4c00b912bb0c58d)

- - - - -
2df830a1 by Cheng Shao at 2023-02-07T18:47:09+05:30
Fix typo in recent darwin tests fix

Corrects a typo in !9647. Otherwise T18623 will still fail on darwin
and stall other people's work.

(cherry picked from commit c45a5fffef2c76efbf5d3a009c3f6d0244a63f0d)

- - - - -
15d34a97 by Ben Gamari at 2023-02-07T18:47:09+05:30
nativeGen/AArch64: Fix debugging output

Previously various panics would rely on a half-written Show
instance, leading to very unhelpful errors. Fix this.

See #22798.

(cherry picked from commit be417a47c7695998dea0adc05489a7b8838a78b6)

- - - - -
34baa6e9 by Ben Gamari at 2023-02-07T18:47:10+05:30
nativeGen: Teach graph-colouring allocator that x18 is unusable

Previously trivColourable for AArch64 claimed that at 18 registers were
trivially-colourable. This is incorrect as x18 is reserved by the platform on
AArch64/Darwin.

See #22798.

(cherry picked from commit 30989d137b8f3a8fddbfd116e04b48f23c24f86c)

- - - - -
d5eea69c by Ben Gamari at 2023-02-07T18:47:10+05:30
nativeGen/AArch64: Fix graph-colouring allocator

Previously various `Instr` queries used by the graph-colouring allocator
failed to handle a few pseudo-instructions. This manifested in compiler
panicks while compiling `SHA`, which uses `-fregs-graph`.

Fixes #22798.

(cherry picked from commit 7566fd9de38c67360c090f828923d41587af519c)

- - - - -
8d846b8a by Ben Gamari at 2023-02-07T18:47:10+05:30
testsuite: Add regression test for #22798

(cherry picked from commit 2cb500a5ee1a31dfe1a2cdd71f175442026eb082)

- - - - -
7262d71f by Zubin Duggal at 2023-02-07T18:47:10+05:30
hadrian: enable -haddock in perf flavour (#22734)

- - - - -
0b54f4cd by Zubin Duggal at 2023-02-07T18:47:10+05:30
Bump version to GHC 9.2.6 and add changelog entries

- - - - -


30 changed files:

- compiler/GHC.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/Reg/Graph/TrivColorable.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/CoreToStg.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/Tc/Instance/Typeable.hs
- compiler/cbits/keepCAFsForGHCi.c
- compiler/ghc.mk
- configure.ac
- docs/users_guide/9.2.1-notes.rst
- + docs/users_guide/9.2.6-notes.rst
- docs/users_guide/bugs.rst
- docs/users_guide/release-notes.rst
- hadrian/src/Settings/Flavours/Performance.hs
- libraries/bytestring
- libraries/ghc-bignum/gmp/gmp-tarballs
- + m4/fp_ld_no_fixup_chains.m4
- rts/Sparks.c
- rts/eventlog/EventLog.c
- rts/sm/GC.c
- + testsuite/tests/ado/T22483.hs
- + testsuite/tests/ado/T22483.stderr
- testsuite/tests/ado/all.T
- + testsuite/tests/codeGen/should_run/T22798.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/25ee38493347d44162809716b5ad317942181ff9...0b54f4cd66d8c5d2983e6570d82c85674fe6b3c9

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/25ee38493347d44162809716b5ad317942181ff9...0b54f4cd66d8c5d2983e6570d82c85674fe6b3c9
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/20230207/12efc029/attachment-0001.html>


More information about the ghc-commits mailing list