[Git][ghc/ghc][wip/simplifier-tweaks] 37 commits: nativeGen: Explicitly set flags of text sections on Windows
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Wed Jul 26 11:09:22 UTC 2023
Simon Peyton Jones pushed to branch wip/simplifier-tweaks at Glasgow Haskell Compiler / GHC
Commits:
3ece9856 by Ben Gamari at 2023-07-21T07:30:45-04:00
nativeGen: Explicitly set flags of text sections on Windows
The binutils documentation (for COFF) claims,
> If no flags are specified, the default flags depend upon the section
> name. If the section name is not recognized, the default will be for the
> section to be loaded and writable.
We previously assumed that this would do the right thing for split
sections (e.g. a section named `.text$foo` would be correctly inferred
to be a text section). However, we have observed that this is not the
case (at least under the clang toolchain used on Windows): when
split-sections is enabled, text sections are treated by the assembler as
data (matching the "default" behavior specified by the documentation).
Avoid this by setting section flags explicitly. This should fix split
sections on Windows.
Fixes #22834.
- - - - -
db7f7240 by Ben Gamari at 2023-07-21T07:30:45-04:00
nativeGen: Set explicit section types on all platforms
- - - - -
b444c16f by Finley McIlwaine at 2023-07-21T07:31:28-04:00
Insert documentation into parsed signature modules
Causes haddock comments in signature modules to be properly
inserted into the AST (just as they are for regular modules)
if the `-haddock` flag is given.
Also adds a test that compares `-ddump-parsed-ast` output
for a signature module to prevent further regressions.
Fixes #23315
- - - - -
c30cea53 by Ben Gamari at 2023-07-21T23:23:49-04:00
primops: Introduce unsafeThawByteArray#
This addresses an odd asymmetry in the ByteArray# primops, which
previously provided unsafeFreezeByteArray# but no corresponding
thaw operation.
Closes #22710
- - - - -
87f9bd47 by Ben Gamari at 2023-07-21T23:23:49-04:00
testsuite: Elaborate in interface stability README
This discussion didn't make it into the original MR.
- - - - -
e4350b41 by Matthew Pickering at 2023-07-21T23:24:25-04:00
Allow users to override non-essential haddock options in a Flavour
We now supply the non-essential options to haddock using the `extraArgs`
field, which can be specified in a Flavour so that if an advanced user
wants to change how documentation is generated then they can use
something other than the `defaultHaddockExtraArgs`.
This does have the potential to regress some packaging if a user has
overridden `extraArgs` themselves, because now they also need to add
the haddock options to extraArgs. This can easily be done by appending
`defaultHaddockExtraArgs` to their extraArgs invocation but someone
might not notice this behaviour has changed.
In any case, I think passing the non-essential options in this manner is
the right thing to do and matches what we do for the "ghc" builder,
which by default doesn't pass any optmisation levels, and would likewise
be very bad if someone didn't pass suitable `-O` levels for builds.
Fixes #23625
- - - - -
fc186b0c by Ilias Tsitsimpis at 2023-07-21T23:25:03-04:00
ghc-prim: Link against libatomic
Commit b4d39adbb58 made 'hs_cmpxchg64()' available to all architectures.
Unfortunately this made GHC to fail to build on armel, since armel needs
libatomic to support atomic operations on 64-bit word sizes.
Configure libraries/ghc-prim/ghc-prim.cabal to link against libatomic,
the same way as we do in rts/rts.cabal.
- - - - -
4f5538a8 by Matthew Pickering at 2023-07-21T23:25:39-04:00
simplifier: Correct InScopeSet in rule matching
The in-scope set passedto the `exprIsLambda_maybe` call lacked all the
in-scope binders. @simonpj suggests this fix where we augment the
in-scope set with the free variables of expression which fixes this
failure mode in quite a direct way.
Fixes #23630
- - - - -
5ad8d597 by Krzysztof Gogolewski at 2023-07-21T23:26:17-04:00
Add a test for #23413
It was fixed by commit e1590ddc661d6: Add the SolverStage monad.
- - - - -
7e05f6df by sheaf at 2023-07-21T23:26:56-04:00
Finish migration of diagnostics in GHC.Tc.Validity
This patch finishes migrating the error messages in GHC.Tc.Validity
to use the new diagnostic infrastructure.
It also refactors the error message datatypes for class and family
instances, to common them up under a single datatype as much as possible.
- - - - -
4876fddc by Matthew Pickering at 2023-07-21T23:27:33-04:00
ci: Enable some more jobs to run in a marge batch
In !10907 I made the majority of jobs not run on a validate pipeline but
then forgot to renable a select few jobs on the marge batch MR.
- - - - -
026991d7 by Jens Petersen at 2023-07-21T23:28:13-04:00
user_guide/flags.py: python-3.12 no longer includes distutils
packaging.version seems able to handle this fine
- - - - -
b91bbc2b by Matthew Pickering at 2023-07-21T23:28:50-04:00
ci: Mention ~full-ci label in MR template
We mention that if you need a full validation pipeline then you can
apply the ~full-ci label to your MR in order to test against the full
validation pipeline (like we do for marge).
- - - - -
42b05e9b by sheaf at 2023-07-22T12:36:00-04:00
RTS: declare setKeepCAFs symbol
Commit 08ba8720 failed to declare the dependency of keepCAFsForGHCi on
the symbol setKeepCAFs in the RTS, which led to undefined symbol errors
on Windows, as exhibited by the testcase frontend001.
Thanks to Moritz Angermann and Ryan Scott for the diagnosis and fix.
Fixes #22961
- - - - -
a72015d6 by sheaf at 2023-07-22T12:36:01-04:00
Mark plugins-external as broken on Windows
This test is broken on Windows, so we explicitly mark it as such now
that we stop skipping plugin tests on Windows.
- - - - -
cb9c93d7 by sheaf at 2023-07-22T12:36:01-04:00
Stop marking plugin tests as fragile on Windows
Now that b2bb3e62 has landed we are in a better situation with
regards to plugins on Windows, allowing us to unmark many plugin tests
as fragile.
Fixes #16405
- - - - -
a7349217 by Krzysztof Gogolewski at 2023-07-22T12:36:37-04:00
Misc cleanup
- Remove unused RDR names
- Fix typos in comments
- Deriving: simplify boxConTbl and remove unused litConTbl
- chmod -x GHC/Exts.hs, this seems accidental
- - - - -
33b6850a by Vladislav Zavialov at 2023-07-23T10:27:37-04:00
Visible forall in types of terms: Part 1 (#22326)
This patch implements part 1 of GHC Proposal #281,
introducing explicit `type` patterns and `type` arguments.
Summary of the changes:
1. New extension flag:
RequiredTypeArguments
2. New user-facing syntax:
`type p` patterns (represented by EmbTyPat)
`type e` expressions (represented by HsEmbTy)
3. Functions with required type arguments (visible forall)
can now be defined and applied:
idv :: forall a -> a -> a -- signature (relevant change: checkVdqOK in GHC/Tc/Validity.hs)
idv (type a) (x :: a) = x -- definition (relevant change: tcPats in GHC/Tc/Gen/Pat.hs)
x = idv (type Int) 42 -- usage (relevant change: tcInstFun in GHC/Tc/Gen/App.hs)
4. template-haskell support:
TH.TypeE corresponds to HsEmbTy
TH.TypeP corresponds to EmbTyPat
5. Test cases and a new User's Guide section
Changes *not* included here are the t2t (term-to-type) transformation
and term variable capture; those belong to part 2.
- - - - -
73b5c7ce by sheaf at 2023-07-23T10:28:18-04:00
Add test for #22424
This is a simple Template Haskell test in which we refer to
record selectors by their exact Names, in two different ways.
Fixes #22424
- - - - -
83cbc672 by Ben Gamari at 2023-07-24T07:40:49+00:00
ghc-toolchain: Initial commit
- - - - -
31dcd26c by Rodrigo Mesquita at 2023-07-24T07:40:49+00:00
ghc-toolchain: Toolchain Selection
This commit integrates ghc-toolchain, the brand new way of configuring
toolchains for GHC, with the Hadrian build system, with configure, and
extends and improves the first iteration of ghc-toolchain.
The general overview is
* We introduce a program invoked `ghc-toolchain --triple=...` which, when run,
produces a file with a `Target`. A `GHC.Toolchain.Target.Target`
describes the properties of a target and the toolchain (executables
and configured flags) to produce code for that target
* Hadrian was modified to read Target files, and will both
* Invoke the toolchain configured in the Target file as needed
* Produce a `settings` file for GHC based on the Target file for that stage
* `./configure` will invoke ghc-toolchain to generate target files, but
it will also generate target files based on the flags configure itself
configured (through `.in` files that are substituted)
* By default, the Targets generated by configure are still (for now) the ones used by Hadrian
* But we additionally validate the Target files generated by
ghc-toolchain against the ones generated by configure, to get a head
start on catching configuration bugs before we transition
completely.
* When we make that transition, we will want to drop a lot of the
toolchain configuration logic from configure, but keep it otherwise.
* For each compiler stage we should have 1 target file (up to a stage compiler we can't run in our machine)
* We just have a HOST target file, which we use as the target for stage0
* And a TARGET target file, which we use for stage1 (and later stages, if not cross compiling)
* Note there is no BUILD target file, because we only support cross compilation where BUILD=HOST
* (for more details on cross-compilation see discussion on !9263)
See also
* Note [How we configure the bundled windows toolchain]
* Note [ghc-toolchain consistency checking]
* Note [ghc-toolchain overview]
Ticket: #19877
MR: !9263
- - - - -
a732b6d3 by Rodrigo Mesquita at 2023-07-24T07:40:49+00:00
Add flag to enable/disable ghc-toolchain based configurations
This flag is disabled by default, and we'll use the
configure-generated-toolchains by default until we remove the toolchain
configuration logic from configure.
- - - - -
61eea240 by Rodrigo Mesquita at 2023-07-24T07:40:49+00:00
Split ghc-toolchain executable to new packge
In light of #23690, we split the ghc-toolchain executable out of the
library package to be able to ship it in the bindist using Hadrian.
Ideally, we eventually revert this commit.
- - - - -
38e795ff by Rodrigo Mesquita at 2023-07-24T07:40:49+00:00
Ship ghc-toolchain in the bindist
Add the ghc-toolchain binary to the binary distribution we ship to
users, and teach the bindist configure to use the existing ghc-toolchain.
- - - - -
32cae784 by Matthew Craven at 2023-07-24T16:48:24-04:00
Kill off gen_bytearray_addr_access_ops.py
The relevant primop descriptions are now
generated directly by genprimopcode.
This makes progress toward fixing #23490, but it is not
a complete fix since there is more than one way in which
cabal-reinstall (hadrian/build build-cabal) is broken.
- - - - -
02e6a6ce by Matthew Pickering at 2023-07-24T16:49:00-04:00
compiler: Remove unused `containers.h` include
Fixes #23712
- - - - -
822ef66b by Matthew Pickering at 2023-07-25T08:44:50-04:00
Fix pretty printing of WARNING pragmas
There is still something quite unsavoury going on with WARNING pragma
printing because the printing relies on the fact that for decl
deprecations the SourceText of WarningTxt is empty. However, I let that
lion sleep and just fixed things directly.
Fixes #23465
- - - - -
e7b38ede by Matthew Pickering at 2023-07-25T08:45:28-04:00
ci-images: Bump to commit which has 9.6 image
The test-bootstrap job has been failing for 9.6 because we accidentally
used a non-master commit.
- - - - -
bb408936 by Matthew Pickering at 2023-07-25T08:45:28-04:00
Update bootstrap plans for 9.6.2 and 9.4.5
- - - - -
6ae42f56 by Simon Peyton Jones at 2023-07-26T10:27:25+01:00
Make the occurrence analyser smarter about join points
This MR addresses #22404. There is a big Note
Note [Occurrence analysis for join points]
that explains it all. Significant changes
* New field occ_join_points in OccEnv
* The NonRec case of occAnalBind splits into two cases:
one for existing join points (which does the special magic for
Note [Occurrence analysis for join points], and one for other
bindings.
* mkOneOcc adds in info from occ_join_points.
* All "bring into scope" activity is centralised in the
new function `addInScope`.
* I made a local data type LocalOcc for use inside the occurrence analyser
It is like OccInfo, but lacks IAmDead and IAmALoopBreaker, which in turn
makes computationns over it simpler and more efficient.
* I found quite a bit of allocation in GHC.Core.Rules.getRules
so I optimised it a bit.
More minor changes
* Renamed data constructor WithUsageDetails to WUD, and
WithTailUsageDetails to WTUD
--------- Compiler perf -----------
I spent quite a time on performance tuning, so even though it
does more than before, the occurrence analyser runs slightly faster
on average. Here are the compile-time allocation changes over 1%
CoOpt_Read(normal) ghc/alloc 766,003,076 748,985,544 -2.2% GOOD
T10858(normal) ghc/alloc 120,782,748 118,735,744 -1.7%
T11545(normal) ghc/alloc 79,829,332 78,722,128 -1.4%
T12150(optasm) ghc/alloc 73,881,192 72,854,208 -1.4%
T13056(optasm) ghc/alloc 294,495,436 290,226,600 -1.4%
T13253(normal) ghc/alloc 364,663,144 361,043,432 -1.0%
T13253-spj(normal) ghc/alloc 118,248,796 59,996,856 -49.3% GOOD
T15164(normal) ghc/alloc 1,102,607,920 1,087,375,984 -1.4%
T15304(normal) ghc/alloc 1,196,061,524 1,155,296,336 -3.4%
T15630(normal) ghc/alloc 148,707,300 147,104,768 -1.1%
T17516(normal) ghc/alloc 1,657,993,132 1,626,735,192 -1.9%
T17836(normal) ghc/alloc 395,306,932 391,219,640 -1.0%
T18140(normal) ghc/alloc 71,948,496 73,206,920 +1.7%
T18282(normal) ghc/alloc 129,090,864 131,483,440 +1.9%
T18698b(normal) ghc/alloc 230,313,396 233,017,416 +1.2% BAD
T4801(normal) ghc/alloc 247,568,452 250,836,624 +1.3%
T9233(normal) ghc/alloc 709,634,020 685,363,720 -3.4% GOOD
T9630(normal) ghc/alloc 965,838,132 942,010,984 -2.5% GOOD
T9675(optasm) ghc/alloc 444,583,940 429,417,416 -3.4% GOOD
T9961(normal) ghc/alloc 303,041,544 307,384,192 +1.4% BAD
WWRec(normal) ghc/alloc 503,706,372 495,554,224 -1.6%
geo. mean -1.0%
minimum -49.3%
maximum +1.9%
The big win on T13253-spj comes because it has a big nest of join
points, each occurring twice in the next one. The new occ-anal takes
only one iteration of the simplifier to do the inlining; the old one
took four. Moreover, we get much smaller code with the new one:
New: Result size of Tidy Core
= {terms: 429, types: 84, coercions: 0, joins: 14/14}
Old: Result size of Tidy Core
= {terms: 2,437, types: 304, coercions: 0, joins: 10/10}
--------- Runtime perf -----------
No significant changes in nofib results, except a 1% reduction in
compiler allocation.
Metric Decrease:
CoOpt_Read
T13253-spj
T9233
T9630
T9675
Metric Increase:
T18698b
T9961
- - - - -
fb18db2e by Simon Peyton Jones at 2023-07-26T10:33:03+01:00
Several improvements to the handling of coercions
* Make `mkSymCo` and `mkInstCo` smarter
Fixes #23642
* Fix return role of `SelCo` in the coercion optimiser.
Fixes #23617
* Make the coercion optimiser `opt_trans_rule` work better for newtypes
Fixes #23619
- - - - -
3241f424 by Simon Peyton Jones at 2023-07-26T10:33:03+01:00
Simplifier improvements
This MR started as: allow the simplifer to do more in one pass,
arising from places I could see the simplifier taking two iterations
where one would do. But it turned into a larger project, because
these changes unexpectedly made inlining blow up, especially join
points in deeply-nested cases.
The net result is good: a 2% improvement in compile time. The table
below shows changes over 1%.
The main changes are:
* The SimplEnv now has a seInlineDepth field, which says how deep
in unfoldings we are. See Note [Inline depth] in Simplify.Env
* Avoid repeatedly simplifying coercions.
see Note [Avoid re-simplifying coercions] in Simplify.Iteration
As you'll see from the Note, this makes use of the seInlineDepth.
* Allow Simplify.Utils.postInlineUnconditionally to inline variables
that are used exactly once. See Note [Post-inline for single-use things].
* Allow Simplify.Iteration.simplAuxBind to inline used-once things.
This is another part of Note [Post-inline for single-use things], and
is really good for reducing simplifier iterations in situations like
case K e of { K x -> blah }
wher x is used once in blah.
* Make GHC.Core.SimpleOpt.exprIsConApp_maybe do some simple case
elimination. Note [Case elim in exprIsConApp_maybe]
* When making join points, don't do so if the join point is so small
it will immediately be inlined. See Note [Duplicating alternatives]
* Do not add an unfolding to a join point at birth. This is a tricky one
and has a long Note [Do not add unfoldings to join points at birth]
It shows up in two places
- In `mkDupableAlt` do not add an inlining
- (trickier) In `simplLetUnfolding` don't add an unfolding for a
fresh join point
I am not fully satisifed with this, but it works and is well documented.
* Many new or rewritten Notes. E.g. Note [Avoiding simplifying repeatedly]
I discovered that GHC.HsToCore.Pmc.Solver.Types.trvVarInfo was very
delicately balanced. It's a small, heavily used, overloaded function
and it's important that it inlines. By a fluke it was before, but at
various times in my journey it stopped doing so. So I added an INLINE
pragma to it.
Metrics: compile_time/bytes allocated
------------------------------------------------
CoOpt_Singletons(normal) -4.3% GOOD
LargeRecord(normal) -23.3% GOOD
PmSeriesS(normal) -2.4%
T11195(normal) -1.7%
T12227(normal) -20.0% GOOD
T12545(normal) -5.4%
T13253-spj(normal) -50.7% GOOD
T13386(normal) -5.1% GOOD
T14766(normal) -2.4% GOOD
T15164(normal) -1.7%
T15304(normal) +1.0%
T15630(normal) -7.7%
T15630a(normal) NEW
T15703(normal) -7.5% GOOD
T16577(normal) -5.1% GOOD
T17516(normal) -3.6%
T18223(normal) -16.8% GOOD
T18282(normal) -1.5%
T18304(normal) +1.9%
T21839c(normal) -3.5% GOOD
T3064(normal) -1.5%
T5030(normal) -16.2% GOOD
T5321Fun(normal) -1.6%
T6048(optasm) -2.1% GOOD
T8095(normal) -6.1% GOOD
T9630(normal) -5.1% GOOD
WWRec(normal) -1.6%
geo. mean -2.1%
minimum -50.7%
maximum +1.9%
Metric Decrease:
CoOpt_Singletons
LargeRecord
T12227
T13253-spj
T13386
T14766
T15703
T16577
T18223
T21839c
T5030
T6048
T8095
T9630
- - - - -
9e54f7b0 by Simon Peyton Jones at 2023-07-26T10:33:03+01:00
No postInlineUnconditionally for strict bindings
Does not save allocation!
- - - - -
4aad7d06 by Simon Peyton Jones at 2023-07-26T10:33:03+01:00
No preInlineConditionally for join points
Does not save allocation!
- - - - -
0e060faa by Simon Peyton Jones at 2023-07-26T10:33:03+01:00
Don't use Plan A for a case continuation
See carryPropagate in digits-of-e2
Really I'm moving more towards Plan B.
- - - - -
06c72027 by Simon Peyton Jones at 2023-07-26T10:33:03+01:00
Fix merge bugs
- - - - -
21d05c53 by Simon Peyton Jones at 2023-07-26T10:33:04+01:00
Further wibbles
In particular simplifying SelCo in Coercion.Opt
- - - - -
17 changed files:
- .gitlab-ci.yml
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- .gitlab/merge_request_templates/Default.md
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Names/TH.hs
- − compiler/GHC/Builtin/gen_bytearray_addr_access_ops.py
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/CmmToAsm/Ppr.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Inline.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6f86cc3bddfd6ca88d437cf86fef2d221c114001...21d05c534c05bd4c9b9ec16589199e6a446a2ec6
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6f86cc3bddfd6ca88d437cf86fef2d221c114001...21d05c534c05bd4c9b9ec16589199e6a446a2ec6
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/20230726/1c59af6f/attachment-0001.html>
More information about the ghc-commits
mailing list