[Git][ghc/ghc][wip/T21286] 47 commits: Add native delimited continuations to the RTS
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Tue Sep 20 10:28:11 UTC 2022
Simon Peyton Jones pushed to branch wip/T21286 at Glasgow Haskell Compiler / GHC
Commits:
04062510 by Alexis King at 2022-09-11T11:30:32+02:00
Add native delimited continuations to the RTS
This patch implements GHC proposal 313, "Delimited continuation
primops", by adding native support for delimited continuations to the
GHC RTS.
All things considered, the patch is relatively small. It almost
exclusively consists of changes to the RTS; the compiler itself is
essentially unaffected. The primops come with fairly extensive Haddock
documentation, and an overview of the implementation strategy is given
in the Notes in rts/Continuation.c.
This first stab at the implementation prioritizes simplicity over
performance. Most notably, every continuation is always stored as a
single, contiguous chunk of stack. If one of these chunks is
particularly large, it can result in poor performance, as the current
implementation does not attempt to cleverly squeeze a subset of the
stack frames into the existing stack: it must fit all at once. If this
proves to be a performance issue in practice, a cleverer strategy would
be a worthwhile target for future improvements.
- - - - -
ee471dfb by Cheng Shao at 2022-09-12T07:07:33-04:00
rts: fix missing dirty_MVAR argument in stg_writeIOPortzh
- - - - -
a5f9c35f by Cheng Shao at 2022-09-12T13:29:05-04:00
ci: enable parallel compression for xz
- - - - -
3a815f30 by Ryan Scott at 2022-09-12T13:29:41-04:00
Windows: Always define _UCRT when compiling C code
As seen in #22159, this is required to ensure correct behavior when MinGW-w64
headers are in the `C_INCLUDE_PATH`.
Fixes #22159.
- - - - -
65a0bd69 by sheaf at 2022-09-13T10:27:52-04:00
Add diagnostic codes
This MR adds diagnostic codes, assigning unique numeric codes to
error and warnings, e.g.
error: [GHC-53633]
Pattern match is redundant
This is achieved as follows:
- a type family GhcDiagnosticCode that gives the diagnostic code
for each diagnostic constructor,
- a type family ConRecursInto that specifies whether to recur into
an argument of the constructor to obtain a more fine-grained code
(e.g. different error codes for different 'deriving' errors),
- generics machinery to generate the value-level function assigning
each diagnostic its error code; see Note [Diagnostic codes using generics]
in GHC.Types.Error.Codes.
The upshot is that, to add a new diagnostic code, contributors only need
to modify the two type families mentioned above. All logic relating to
diagnostic codes is thus contained to the GHC.Types.Error.Codes module,
with no code duplication.
This MR also refactors error message datatypes a bit, ensuring we can
derive Generic for them, and cleans up the logic around constraint
solver reports by splitting up 'TcSolverReportInfo' into separate
datatypes (see #20772).
Fixes #21684
- - - - -
362cca13 by sheaf at 2022-09-13T10:27:53-04:00
Diagnostic codes: acccept test changes
The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.
- - - - -
08f6730c by Adam Gundry at 2022-09-13T10:28:29-04:00
Allow imports to reference multiple fields with the same name (#21625)
If a module `M` exports two fields `f` (using DuplicateRecordFields), we can
still accept
import M (f)
import M hiding (f)
and treat `f` as referencing both of them. This was accepted in GHC 9.0, but gave
rise to an ambiguity error in GHC 9.2. See #21625.
This patch also documents this behaviour in the user's guide, and updates the
test for #16745 which is now treated differently.
- - - - -
c14370d7 by Cheng Shao at 2022-09-13T10:29:07-04:00
ci: remove unused appveyor config
- - - - -
dc6af9ed by Cheng Shao at 2022-09-13T10:29:45-04:00
compiler: remove unused lazy state monad
- - - - -
646d15ad by Eric Lindblad at 2022-09-14T03:13:56-04:00
Fix typos
This fixes various typos and spelling mistakes
in the compiler.
Fixes #21891
- - - - -
7d7e71b0 by Matthew Pickering at 2022-09-14T03:14:32-04:00
hadrian: Bump index state
This bumps the index state so a build plan can also be found when
booting with 9.4.
Fixes #22165
- - - - -
98b62871 by Matthew Pickering at 2022-09-14T17:17:04-04:00
hadrian: Use a stamp file to record when a package is built in a certain way
Before this patch which library ways we had built wasn't recorded
directly. So you would run into issues if you build the .conf file with
some library ways before switching the library ways which you wanted to
build.
Now there is one stamp file for each way, so in order to build a
specific way you can need that specific stamp file rather than going
indirectly via the .conf file.
- - - - -
b42cedbe by Matthew Pickering at 2022-09-14T17:17:04-04:00
hadrian: Inplace/Final package databases
There are now two different package databases per stage. An inplace
package database contains .conf files which point directly into the
build directories. The final package database contains .conf files which
point into the installed locations. The inplace .conf files are created
before any building happens and have fake ABI hash values. The final
.conf files are created after a package finished building and contains
the proper ABI has.
The motivation for this is to make the dependency structure more
fine-grained when building modules. Now a module depends just depends
directly on M.o from package p rather than the .conf file depend on the
.conf file for package p. So when all of a modules direct dependencies
have finished building we can start building it rather than waiting for
the whole package to finish.
The secondary motivation is that the multi-repl doesn't need to build
everything before starting the multi-repl session. We can just configure
the inplace package-db and use that in order to start the repl.
- - - - -
6515c32b by Matthew Pickering at 2022-09-14T17:17:04-04:00
hadrian: Add some more packages to multi-cradle
The main improvement here is to pass `-this-unit-id` for executables so
that they can be added to the multi-cradle if desired as well as normal
library packages.
- - - - -
e470e91f by Matthew Pickering at 2022-09-14T17:17:04-04:00
hadrian: Need builders needed by Cabal Configure in parallel
Because of the use of withStaged (which needs the necessary builder)
when configuring a package, the builds of stage1:exe:ghc-bin and
stage1:exe:ghc-pkg where being linearised when building a specific
target like `binary-dist-dir`.
Thankfully the fix is quite local, to supply all the `withStaged`
arguments together so the needs can be batched together and hence
performed in parallel.
Fixes #22093
- - - - -
c4438347 by Matthew Pickering at 2022-09-14T17:17:04-04:00
Remove stage1:exe:ghc-bin pre-build from CI script
CI builds stage1:exe:ghc-bin before the binary-dist target which
introduces some quite bad linearisation (see #22093) because we don't
build stage1 compiler in parallel with anything. Then when the
binary-dist target is started we have to build stage1:exe:ghc-pkg before
doing anything.
Fixes #22094
- - - - -
71d8db86 by Matthew Pickering at 2022-09-14T17:17:04-04:00
hadrian: Add extra implicit dependencies from DeriveLift
ghc -M should know that modules which use DeriveLift (or
TemplateHaskellQuotes) need TH.Lib.Internal but until it does, we have
to add these extra edges manually or the modules will be compiled before
TH.Lib.Internal is compiled which leads to a desugarer error.
- - - - -
43e574f0 by Greg Steuck at 2022-09-14T17:17:43-04:00
Repair c++ probing on OpenBSD
Failure without this change:
```
checking C++ standard library flavour... libc++
checking for linkage against 'c++ c++abi'... failed
checking for linkage against 'c++ cxxrt'... failed
configure: error: Failed to find C++ standard library
```
- - - - -
534b39ee by Douglas Wilson at 2022-09-14T17:18:21-04:00
libraries: template-haskell: vendor filepath differently
Vendoring with ../ in hs-source-dirs prevents upload to hackage.
(cherry picked from commit 1446be7586ba70f9136496f9b67f792955447842)
- - - - -
bdd61cd6 by M Farkas-Dyck at 2022-09-14T22:39:34-04:00
Unbreak Hadrian with Cabal 3.8.
- - - - -
df04d6ec by Krzysztof Gogolewski at 2022-09-14T22:40:09-04:00
Fix typos
- - - - -
d6ea8356 by Andreas Klebinger at 2022-09-15T10:12:41+02:00
Tag inference: Fix #21954 by retaining tagsigs of vars in function position.
For an expression like:
case x of y
Con z -> z
If we also retain the tag sig for z we can generate code to immediately return
it rather than calling out to stg_ap_0_fast.
- - - - -
7cce7007 by Andreas Klebinger at 2022-09-15T10:12:42+02:00
Stg.InferTags.Rewrite - Avoid some thunks.
- - - - -
88c4cbdb by Cheng Shao at 2022-09-16T13:57:56-04:00
hadrian: enable -fprof-late only for profiling ways
- - - - -
d7235831 by Cheng Shao at 2022-09-16T13:57:56-04:00
hadrian: add late_ccs flavour transformer
- - - - -
ce203753 by Cheng Shao at 2022-09-16T13:58:34-04:00
configure: remove unused program checks
- - - - -
9b4c1056 by Pierre Le Marre at 2022-09-16T13:59:16-04:00
Update to Unicode 15.0
- - - - -
c6e9b89a by Bodigrim at 2022-09-16T13:59:55-04:00
Avoid partial head and tail in ghc-heap; replace with total pattern-matching
- - - - -
616afde3 by Cheng Shao at 2022-09-16T14:00:33-04:00
hadrian: relax Cabal upper bound to allow building with Cabal-3.8
A follow up of !8910.
- - - - -
df35d994 by Alexis King at 2022-09-16T14:01:11-04:00
Add links to the continuations haddocks in the docs for each primop
fixes #22176
- - - - -
383f7549 by Matthew Pickering at 2022-09-16T21:42:10-04:00
-Wunused-pattern-binds: Recurse into patterns to check whether there's a splice
See the examples in #22057 which show we have to traverse deeply into a
pattern to determine whether it contains a splice or not. The original
implementation pointed this out but deemed this very shallow traversal
"too expensive".
Fixes #22057
I also fixed an oversight in !7821 which meant we lost a warning which
was present in 9.2.2.
Fixes #22067
- - - - -
5031bf49 by sheaf at 2022-09-16T21:42:49-04:00
Hadrian: Don't try to build terminfo on Windows
Commit b42cedbe introduced a dependency on terminfo on Windows,
but that package isn't available on Windows.
- - - - -
c9afe221 by M Farkas-Dyck at 2022-09-17T06:44:47-04:00
Clean up some. In particular:
• Delete some dead code, largely under `GHC.Utils`.
• Clean up a few definitions in `GHC.Utils.(Misc, Monad)`.
• Clean up `GHC.Types.SrcLoc`.
• Derive stock `Functor, Foldable, Traversable` for more types.
• Derive more instances for newtypes.
Bump haddock submodule.
- - - - -
85431ac3 by Cheng Shao at 2022-09-17T06:45:25-04:00
driver: pass original Cmm filename in ModLocation
When compiling Cmm, the ml_hs_file field is used to indicate Cmm
filename when later generating DWARF information. We should pass the
original filename here, otherwise for preprocessed Cmm files, the
filename will be a temporary filename which is confusing.
- - - - -
63aa0069 by Cheng Shao at 2022-09-17T06:46:04-04:00
rts: remove legacy logging cabal flag
- - - - -
bd0f4184 by Cheng Shao at 2022-09-17T06:46:04-04:00
rts: make threaded ways optional
For certain targets (e.g. wasm32-wasi), the threaded rts is known not to
work. This patch adds a "threaded" cabal flag to rts to make threaded
rts ways optional. Hadrian enables this flag iff the flavour rtsWays
contains threaded ways.
- - - - -
8a666ad2 by Ryan Scott at 2022-09-18T08:00:44-04:00
DeriveFunctor: Check for last type variables using dataConUnivTyVars
Previously, derived instances of `Functor` (as well as the related classes
`Foldable`, `Traversable`, and `Generic1`) would determine which constraints to
infer by checking for fields that contain the last type variable. The problem
was that this last type variable was taken from `tyConTyVars`. For GADTs, the
type variables in each data constructor are _not_ the same type variables as
in `tyConTyVars`, leading to #22167.
This fixes the issue by instead checking for the last type variable using
`dataConUnivTyVars`. (This is very similar in spirit to the fix for #21185,
which also replaced an errant use of `tyConTyVars` with type variables from
each data constructor.)
Fixes #22167.
- - - - -
78037167 by Vladislav Zavialov at 2022-09-18T08:01:20-04:00
Lexer: pass updated buffer to actions (#22201)
In the lexer, predicates have the following type:
{ ... } :: user -- predicate state
-> AlexInput -- input stream before the token
-> Int -- length of the token
-> AlexInput -- input stream after the token
-> Bool -- True <=> accept the token
This is documented in the Alex manual.
There is access to the input stream both before and after the token.
But when the time comes to construct the token, GHC passes only the
initial string buffer to the lexer action. This patch fixes it:
- type Action = PsSpan -> StringBuffer -> Int -> P (PsLocated Token)
+ type Action = PsSpan -> StringBuffer -> Int -> StringBuffer -> P (PsLocated Token)
Now lexer actions have access to the string buffer both before and after
the token, just like the predicates. It's just a matter of passing an
additional function parameter throughout the lexer.
- - - - -
75746594 by Vladislav Zavialov at 2022-09-18T08:01:20-04:00
Lexer: define varsym without predicates (#22201)
Before this patch, the varsym lexing rules were defined as follows:
<0> {
@varsym / { precededByClosingToken `alexAndPred` followedByOpeningToken } { varsym_tight_infix }
@varsym / { followedByOpeningToken } { varsym_prefix }
@varsym / { precededByClosingToken } { varsym_suffix }
@varsym { varsym_loose_infix }
}
Unfortunately, this meant that the predicates 'precededByClosingToken' and
'followedByOpeningToken' were recomputed several times before we could figure
out the whitespace context.
With this patch, we check for whitespace context directly in the lexer
action:
<0> {
@varsym { with_op_ws varsym }
}
The checking for opening/closing tokens happens in 'with_op_ws' now,
which is part of the lexer action rather than the lexer predicate.
- - - - -
c1f81b38 by M Farkas-Dyck at 2022-09-19T09:07:05-04:00
Scrub partiality about `NewOrData`.
Rather than a list of constructors and a `NewOrData` flag, we define `data DataDefnCons a = NewTypeCon a | DataTypeCons [a]`, which enforces a newtype to have exactly one constructor.
Closes #22070.
Bump haddock submodule.
- - - - -
1e1ed8c5 by Cheng Shao at 2022-09-19T09:07:43-04:00
CmmToC: emit __builtin_unreachable() after noreturn ccalls
Emit a __builtin_unreachable() call after a foreign call marked as
CmmNeverReturns. This is crucial to generate correctly typed code for
wasm; as for other archs, this is also beneficial for the C compiler
optimizations.
- - - - -
19f45a25 by Jan Hrček at 2022-09-20T03:49:29-04:00
Document :unadd GHCi command in user guide
- - - - -
545ff490 by sheaf at 2022-09-20T03:50:06-04:00
Hadrian: merge archives even in stage 0
We now always merge .a archives when ar supports -L.
This change is necessary in order to bootstrap GHC using GHC 9.4
on Windows, as nested archives aren't supported.
Not doing so triggered bug #21990 when trying to use the Win32
package, with errors such as:
Not a x86_64 PE+ file.
Unknown COFF 4 type in getHeaderInfo.
ld.lld: error: undefined symbol: Win32zm2zi12zi0zi0_SystemziWin32ziConsoleziCtrlHandler_withConsoleCtrlHandler1_info
We have to be careful about which ar is meant: in stage 0, the check
should be done on the system ar (system-ar in system.config).
- - - - -
59fe128c by Vladislav Zavialov at 2022-09-20T03:50:42-04:00
Fix -Woperator-whitespace for consym (part of #19372)
Due to an oversight, the initial specification and implementation of
-Woperator-whitespace focused on varsym exclusively and completely
ignored consym.
This meant that expressions such as "x+ y" would produce a warning,
while "x:+ y" would not.
The specification was corrected in ghc-proposals pull request #404,
and this patch updates the implementation accordingly.
Regression test included.
- - - - -
d1504eeb by Simon Peyton Jones at 2022-09-20T10:37:37+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) ghc/alloc 6,084,071,354 -50.1% GOOD
ManyConstructors(normal) ghc/alloc 3,928,349,810 +1.7%
MultiLayerModulesTH_OneShot(normal) ghc/alloc 2,523,518,560 +1.2%
T12545(normal) ghc/alloc 1,633,149,272 +3.1%
T13056(optasm) ghc/alloc 349,532,453 -8.7% GOOD
T13253(normal) ghc/alloc 343,592,469 -3.3% GOOD
T15164(normal) ghc/alloc 1,304,125,024 -3.4% GOOD
T16190(normal) ghc/alloc 278,584,392 -1.5%
T16577(normal) ghc/alloc 8,050,423,421 -2.8% GOOD
T17836(normal) ghc/alloc 829,913,981 +2.3%
T18223(normal) ghc/alloc 734,732,288 -33.3% GOOD
T18282(normal) ghc/alloc 150,159,957 -2.9% GOOD
T18478(normal) ghc/alloc 498,300,837 +1.2%
T19695(normal) ghc/alloc 1,444,571,802 -2.5% GOOD
T9630(normal) ghc/alloc 1,523,682,706 -32.8% GOOD
WWRec(normal) ghc/alloc 624,174,317 -9.6% GOOD
hie002(normal) ghc/alloc 9,020,356,301 +1.8%
-------------------------------------------------------------------------
geo. mean -1.7%
minimum -50.1%
maximum +3.1%
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 also got one runtime improvement:
T9203(normal) run/alloc 105,672,160 -10.7% GOOD
but I did not investigate.
Nofib is a wash:
+===============================++===============+===========+
| real/anna || -0.13% | 0.0% |
| real/fem || +0.13% | 0.0% |
| real/fulsom || -0.16% | 0.0% |
| real/gamteb || +0.02% | 0.0% |
| real/gg || +0.01% | 0.0% |
| real/lift || -1.55% | 0.0% |
| real/reptile || -0.11% | 0.0% |
| real/scs || -0.08% | 0.0% |
| real/smallpt || +0.51% | 0.0% |
| real/symalg || -0.01% | 0.0% |
| real/veritas || +0.05% | 0.0% |
| shootout/binary-trees || +0.00% | 0.0% |
| shootout/fannkuch-redux || -0.05% | 0.0% |
| shootout/k-nucleotide || -0.01% | 0.0% |
| shootout/n-body || -0.06% | 0.0% |
| shootout/spectral-norm || +0.01% | 0.0% |
| spectral/constraints || +0.20% | 0.0% |
| spectral/dom-lt || +1.80% | 0.0% |
| spectral/expert || +0.33% | 0.0% |
Metric Decrease:
LargeRecord
T13056
T15164
T16577
T18223
T9630
WWRec
T9203
- - - - -
052dcc0e by Simon Peyton Jones at 2022-09-20T10:37:37+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.
- - - - -
3dfc1773 by Simon Peyton Jones at 2022-09-20T10:37:37+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:
- − .appveyor.sh
- .gitlab/ci.sh
- − appveyor.yml
- compiler/GHC.hs
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/PrimOps.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Builtin/Uniques.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Instr.hs
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/CommonBlockElim.hs
- compiler/GHC/Cmm/ContFlowOpt.hs
- compiler/GHC/Cmm/Dataflow.hs
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/Liveness.hs
- compiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/Reg.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/Cmm/Switch.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CmmToAsm/BlockLayout.hs
- compiler/GHC/CmmToAsm/CFG.hs
- compiler/GHC/CmmToAsm/CFG/Dominators.hs
- compiler/GHC/CmmToAsm/CPrim.hs
- compiler/GHC/CmmToAsm/Monad.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8be40982755fa9872bbf3de0737accdb263c0500...3dfc17739c62a4f553e7a5912e67ee330d386a6a
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8be40982755fa9872bbf3de0737accdb263c0500...3dfc17739c62a4f553e7a5912e67ee330d386a6a
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/20220920/b5532a9a/attachment-0001.html>
More information about the ghc-commits
mailing list