[Git][ghc/ghc][wip/T21286] 20 commits: DmdAnal: Don't panic in addCaseBndrDmd (#22039)
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Fri Sep 9 14:49:57 UTC 2022
Simon Peyton Jones pushed to branch wip/T21286 at Glasgow Haskell Compiler / GHC
Commits:
d2be80fd by Sebastian Graf at 2022-09-05T23:12:14-04:00
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.
- - - - -
25f68ace by Ben Gamari at 2022-09-05T23:12:50-04:00
gitlab-ci: Ensure that ghc derivation is in scope
Previously the lint-ci job attempted to use cabal-install (specifically
`cabal update`) without a GHC in PATH. However, cabal-install-3.8
appears to want GHC, even for `cabal update`.
- - - - -
f37b621f by sheaf at 2022-09-06T11:51:53+00:00
Update instances.rst, clarifying InstanceSigs
Fixes #22103
- - - - -
d4f908f7 by Jan Hrček at 2022-09-06T15:36:58-04:00
Fix :add docs in user guide
- - - - -
808bb793 by Cheng Shao at 2022-09-06T15:37:35-04:00
ci: remove unused build_make/test_make in ci script
- - - - -
d0a2efb2 by Eric Lindblad at 2022-09-07T16:42:45-04:00
typo
- - - - -
fac0098b by Eric Lindblad at 2022-09-07T16:42:45-04:00
typos
- - - - -
a581186f by Eric Lindblad at 2022-09-07T16:42:45-04:00
whitespace
- - - - -
04a738cb by Cheng Shao at 2022-09-07T16:43:22-04:00
CmmToAsm: remove unused ModLocation from NatM_State
- - - - -
ee1cfaa9 by Krzysztof Gogolewski at 2022-09-07T16:43:58-04:00
Minor SDoc cleanup
Change calls to renderWithContext with showSDocOneLine; it's more
efficient and explanatory.
Remove polyPatSig (unused)
- - - - -
7918265d by Krzysztof Gogolewski at 2022-09-07T16:43:58-04:00
Remove Outputable Char instance
Use 'text' instead of 'ppr'.
Using 'ppr' on the list "hello" rendered as "h,e,l,l,o".
- - - - -
77209ab3 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Export liftA2 from Prelude
Changes:
In order to be warning free and compatible, we hide Applicative(..)
from Prelude in a few places and instead import it directly from
Control.Applicative.
Please see the migration guide at
https://github.com/haskell/core-libraries-committee/blob/main/guides/export-lifta2-prelude.md
for more details.
This means that Applicative is now exported in its entirety from
Prelude.
Motivation:
This change is motivated by a few things:
* liftA2 is an often used function, even more so than (<*>) for some
people.
* When implementing Applicative, the compiler will prompt you for either
an implementation of (<*>) or of liftA2, but trying to use the latter
ends with an error, without further imports. This could be confusing
for newbies.
* For teaching, it is often times easier to introduce liftA2 first,
as it is a natural generalisation of fmap.
* This change seems to have been unanimously and enthusiastically
accepted by the CLC members, possibly indicating a lot of love for it.
* This change causes very limited breakage, see the linked issue below
for an investigation on this.
See https://github.com/haskell/core-libraries-committee/issues/50
for the surrounding discussion and more details.
- - - - -
442a94e8 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Add changelog entry for liftA2 export from Prelude
- - - - -
fb968680 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Bump submodule containers to one with liftA2 warnings fixed
- - - - -
f54ff818 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Bump submodule Cabal to one with liftA2 warnings fixed
- - - - -
a4b34808 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Isolate some Applicative hidings to GHC.Prelude
By reexporting the entirety of Applicative from GHC.Prelude, we can save
ourselves some `hiding` and importing of `Applicative` in consumers of GHC.Prelude.
This also has the benefit of isolating this type of change to
GHC.Prelude, so that people in the future don't have to think about it.
- - - - -
9c4ea90c by Cheng Shao at 2022-09-08T17:49:47-04:00
CmmToC: enable 64-bit CallishMachOp on 32-bit targets
Normally, the unregisterised builds avoid generating 64-bit
CallishMachOp in StgToCmm, so CmmToC doesn't support these. However,
there do exist cases where we'd like to invoke cmmToC for other cmm
inputs which may contain such CallishMachOps, and it's a rather low
effort to add support for these since they only require calling into
existing ghc-prim cbits.
- - - - -
190f0d35 by Simon Peyton Jones at 2022-09-09T15:49:24+01:00
Improve aggressive specialisation
This patch fixes #21286, by not unboxing dictionaries in
worker/wrapper (ever). The main payload is tiny:
* In `GHC.Core.Opt.DmdAnal.finaliseArgBoxities`, do not unbox
dictionaries in `get_dmd`. See Note [Do not unbox class dictionaries]
in that modules
* I also found that imported wrappers were being fruitlessly
specialised, so I fixed that too, in canSpecImport.
See Note [Specialising imported functions] point (2).
In doing due diligence in the testsuite I fixed a number of
other things:
* Improve Note [Specialising unfoldings] in GHC.Core.Unfold.Make,
and Note [Inline specialisations] in GHC.Core.Opt.Specialise,
and remove duplication between the two. The new Note describes
how we specialise functions with an INLINABLE pragma.
And simplify the defn of `spec_unf` in `GHC.Core.Opt.Specialise.specCalls`.
* Improve Note [Worker/wrapper for INLINABLE functions] in
GHC.Core.Opt.WorkWrap.
And (critially) make an actual change which is to propagate the
user-written pragma from the original function to the wrapper; see
`mkStrWrapperInlinePrag`.
* Write new Note [Specialising imported functions] in
GHC.Core.Opt.Specialise
All this has a big effect on some compile times:
Metrics: compile_time/bytes allocated
--------------------------------------------------------
LargeRecord(normal) -50.2% GOOD
MultiLayerModulesTH_OneShot(normal) +2.0%
T10547(normal) +1.3%
T12545(normal) -3.9%
T13056(optasm) -8.4% GOOD
T14052(ghci) +1.9%
T15164(normal) -3.5% GOOD
T16577(normal) -2.6% GOOD
T18223(normal) -33.4% GOOD
T3064(normal) +1.5%
T8095(normal) +1.3%
T9630(normal) 32.9% GOOD
WWRec(normal) -9.8% GOOD
hie002(normal) +1.8%
geo. mean -1.5%
I diligently investigated all these big drops.
* Caused by not doing w/w for dictionaries:
T13056, T15164, WWRec, T18223
* Caused by not fruitlesslly specialising wrappers
LargeRecord, T9630
I agonised a bit about some small regressions in
nofib:
# bytes allocated
+===============================++===============+===========+
| real/lift || -1.55% | 0.0% |
| real/maillist || +1.66% | 0.0% |
| real/smallpt || +0.51% | 0.0% |
| shootout/reverse-complement || +4.93% | 0.0% |
| spectral/dom-lt || +1.80% | 0.0% |
ToDo: re-do these figures
Metric Decrease:
LargeRecord
T13056
T15164
T16577
T18223
T9630
WWRec
- - - - -
6a1448c6 by Simon Peyton Jones at 2022-09-09T15:51:21+01:00
Refactor UnfoldingSource and IfaceUnfolding
I finally got tired of the way that IfaceUnfolding reflected
a previous structure of unfoldings, not the current one. This
MR refactors UnfoldingSource and IfaceUnfolding to be simpler
and more consistent.
It's largely just a refactor, but in UnfoldingSource (which moves
to GHC.Types.Basic, since it is now used in IfaceSyn too), I
distinguish between /user-specified/ and /system-generated/ stable
unfoldings.
data UnfoldingSource
= VanillaSrc
| StableUserSrc -- From a user-specified pragma
| StableSystemSrc -- From a system-generated unfolding
| CompulsorySrc
This has a minor effect in CSE (see the use of isisStableUserUnfolding
in GHC.Core.Opt.CSE), which I tripped over when working on
specialisation, but it seems like a Good Thing to know anyway.
- - - - -
cbadbc1a by Simon Peyton Jones at 2022-09-09T15:51:21+01:00
INLINE/INLINEABLE pragmas in Foreign.Marshal.Array
Foreign.Marshal.Array contains many small functions, all of which are
overloaded, and which are critical for performance. Yet none of them
had pragmas, so it was a fluke whether or not they got inlined.
This patch makes them all either INLINE (small ones) or
INLINEABLE and hence specialisable (larger ones).
See Note [Specialising array operations] in that module.
- - - - -
30 changed files:
- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC/ByteCode/Instr.hs
- compiler/GHC/Cmm/Dominators.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/CFG.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/CmmToLlvm/Ppr.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Opt/CSE.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/WorkWrap.hs
- compiler/GHC/Core/Ppr.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Tidy.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Unfold/Make.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cc429374475d3dc9523a263ffda6018c2bdf92ca...cbadbc1a6815da0f2eddfb7c4291f7026a93ad3a
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cc429374475d3dc9523a263ffda6018c2bdf92ca...cbadbc1a6815da0f2eddfb7c4291f7026a93ad3a
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/20220909/ce3346bd/attachment-0001.html>
More information about the ghc-commits
mailing list