[Git][ghc/ghc][wip/T23083] 8 commits: Disable tests RepPolyWrappedVar2 and RepPolyUnsafeCoerce1 in JS backend

Sebastian Graf (@sgraf812) gitlab at gitlab.haskell.org
Wed Aug 9 07:38:09 UTC 2023



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


Commits:
4395ece2 by Sebastian Graf at 2023-08-09T09:37:16+02:00
Disable tests RepPolyWrappedVar2 and RepPolyUnsafeCoerce1 in JS backend

... because those coerce between incompatible/unknown PrimReps.

- - - - -
6165155a by Sebastian Graf at 2023-08-09T09:37:55+02:00
Inlining literals into boring contexts is OK

- - - - -
b4c3378f by Sebastian Graf at 2023-08-09T09:37:55+02:00
Clarify floating of unsafeEqualityProofs (#23754)

- - - - -
13c9d4a1 by Sebastian Graf at 2023-08-09T09:37:55+02:00
Kill SetLevel.notWorthFloating.is_triv (#23270)

We have had it since b84ba676034, when it operated on annotated expressions.
Nowadays it operates on vanilla `CoreExpr` though, so we should just call
`exprIsTrivial`; thus handling empty cases and string literals correctly.

- - - - -
e799b6b1 by Sebastian Graf at 2023-08-09T09:37:55+02:00
ANFise string literal arguments (#23270)

This instates the invariant that a trivial CoreExpr translates to an atomic
StgExpr. Nice.

Annoyingly, in -O0 we sometimes generate
```
foo = case "blah"# of sat { __DEFAULT -> unpackCString# sat }
```
which makes it a bit harder to spot that we can emit a standard
`stg_unpack_cstring` thunk.

Fixes #23270.

- - - - -
298ec2da by Sebastian Graf at 2023-08-09T09:37:55+02:00
Deactivate -fcatch-nonexhaustive-cases in ghc-bignum (#23345)

- - - - -
d5722ebb by Sebastian Graf at 2023-08-09T09:37:55+02:00
CorePrep: Eliminate EmptyCase and unsafeEqualityProof in CoreToStg instead

We eliminate EmptyCase by way of `coreToStg (Case e _ _ []) = coreToStg e` now.
The main reason is that it plays far better in conjunction with eta expansion
(as we aim to do for arguments in CorePrep, #23083), because we can discard
any arguments, `(case e of {}) eta == case e of {}`, whereas in `(e |> co) eta`
it's impossible to discard the argument.

We do also give the same treatment to unsafeCoerce proofs and treat them as
trivial iff their RHS is trivial.

It is also both much simpler to describe than the previous mechanism of emitting
an unsafe coercion and simpler to implement, removing quite a bit of commentary
and `CorePrepProv`.

In the ghc/alloc perf test `LargeRecord`, we introduce an additional Simplifier
iteration due to #17910. E.g., FloatOut produces a binding
```
lvl_s6uK [Occ=Once1] :: GHC.Types.Int
[LclId]
lvl_s6uK = GHC.Types.I# 2#

lvl_s6uL [Occ=Once1] :: GHC.Types.Any
[LclId]
lvl_s6uL
  = case Unsafe.Coerce.unsafeEqualityProof ... of
    { Unsafe.Coerce.UnsafeRefl v2_i6tr -> lvl_s6uK `cast` (... v2_i6tr ...)
    }
```
That occurs once and hence is pre-inlined unconditionally in the next Simplifier
pass. It's non-trivial to find a way around that, but not really harmful
otherwise. Hence we accept a 1.2% increase on some architectures.

Metric Increase:
    LargeRecord

- - - - -
6d0d74cd by Sebastian Graf at 2023-08-09T09:37:55+02:00
CorePrep: Eta expand arguments (#23083)

Previously, we'd only eta expand let bindings and lambdas,
now we'll also eta expand arguments such as in T23083:
```hs
g f h = f (h `seq` (h $))
```
Unless `-fpedantic-bottoms` is set, we'll now transform to
```hs
g f h = f (\eta -> h eta)
```
in CorePrep.

See the new `Note [Eta expansion of arguments in CorePrep]` for the details.

We only do this optimisation with -O2 because we saw 2-3% ghc/alloc regressions
in T4801 and T5321FD.

Fixes #23083.

- - - - -


30 changed files:

- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/CoreToStg.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Config/CoreToStg/Prep.hs
- compiler/GHC/Driver/DynFlags.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/StgToCmm/Bind.hs
- compiler/GHC/StgToCmm/Env.hs
- compiler/GHC/StgToCmm/Expr.hs
- compiler/GHC/StgToJS/Utils.hs
- compiler/GHC/Tc/TyCl/Utils.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b3ed94ae0fef38b7f678f879dcdb4e67a04537a7...6d0d74cd0ea03fcf8a75f3e3aa2dd0e226209afc

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b3ed94ae0fef38b7f678f879dcdb4e67a04537a7...6d0d74cd0ea03fcf8a75f3e3aa2dd0e226209afc
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/20230809/12d86893/attachment.html>


More information about the ghc-commits mailing list