Commits on Source (72)
-
Sylvain Henry authored
shiftR/shiftL support negative arguments despite Haskell 2010 report saying otherwise. We explicitly test for negative values which is bad (it gets in the way of constant folding, etc.). Anyway, for consistency we fix Bits instancesof Integer/Natural.
32496789 -
Sylvain Henry authored
A bug was lingering in Natural multiplication (inverting two limbs) despite QuickCheck tests used during the development leading to wrong results (independently of the selected backend).
b4cccab3 -
Sylvain Henry authored
Also reenable integerPowMod test which had never been reenabled by mistake.
817f94f5 -
Sylvain Henry authored
Also enhance bigNatCheck# and isValidNatural test
eab2511e -
Sylvain Henry authored3745bdb6
-
7cf007cc
-
[skip ci]
205f168c -
29794212
-
There are multiple reasons we want this: - Fewer allocations: ByteString has 3 fields, ShortByteString just has one. - ByteString memory is pinned: - This can cause fragmentation issues (see for example #13110) but also - makes using FastStrings in compact regions impossible. Metric Decrease: T5837 T12150 T12234 T12425
f8804cd8 -
Currently we're passing a indexWord8OffAddr# type function to utf8DecodeLazy# which then passes it on to utf8DecodeChar#. By passing one of utf8DecodeCharAddr# or utf8DecodeCharByteArray# instead we benefit from the inlining and specialization already done for those.
5acdf506 -
a9b46ec3
-
fcb9e94d
-
44b28e97
-
f0fe989d
-
Metric Increase: ManyConstructors Metric Decrease: T4029
59cd5cd4 -
Ben Gamari authored
This fixes the error message given by configure when the user attempts to configure without first download the win32 tarballs.
0f66e49e -
Andreas Klebinger authored
This is only for their respective codebases.
3ecac53c -
Sylvain Henry authored
This flag has been removed in 066b369d in 2011.
dbf77b79 -
Sylvain Henry authored4e22de2a
-
Sylvain Henry authorede27698ce
-
Sylvain Henry authored
Previously we used a platform settings to detect if the native code generator was used. This was wrong. We need to use the `DynFlags.hscTarget` field instead.
666acbd4 -
Sylvain Henry authored
* Represent backends with a `Backend` datatype in GHC.Driver.Backend * Don't detect the default backend to use for the target platform at compile time in Hadrian/make but at runtime. It makes "Settings" simpler and it is a step toward making GHC multi-target. * The latter change also fixes hadrian which has not been updated to take into account that the NCG now supports AIX and PPC64 (cf df26b955 and d3c1dda6) * Also we don't treat iOS specifically anymore (cf cb4878ff)
ce5408c0 -
(cherry picked from commit cdd0ff16)
9751d499 -
(cherry picked from commit c1f4f81d)
5438dcec -
Fixes 18266 (cherry picked from commit fc0f6fbc)
5544d17a -
Ben Gamari authored
Since switching to the two-step allocator, the `outofmem` test fails via `osCommitMemory` failing to commit. However, this was previously exiting with `EXIT_FAILURE`, rather than `EXIT_HEAPOVERFLOW`. I think the latter is a more reasonable exit code for this case and matches the behavior on POSIX platforms. (cherry picked from commit da7269a4)
986063cf -
Ben Gamari authored
(cherry picked from commit f153a1d0)
b2f8c6a7 -
Ben Gamari authored
Previously the old Windows IO manager threw different errors than WinIO. We now canonicalise these to the WinIO errors. (cherry picked from commit e91672f0)
83a0649c -
Ben Gamari authored
Otherwise the Windows builds hang forever waiting for the process to terminate. (cherry picked from commit 9cbfe086)
97ac5b2a -
(cherry picked from commit 8236925f)
8f1154d3 -
(cherry picked from commit ce0a1d67)
39c6fbae -
(cherry picked from commit 52685cf7)
b784c75a -
Ben Gamari authored
As noted in #18487, we have reached the end of this road. (cherry picked from commit aa054d32)
8388567e -
Simon Peyton Jones authored
This patch eta-expands the Simplifier's monad, using the method explained in GHC.Core.Unify Note [The one-shot state monad trick]. It's part of the exta-expansion programme in #18202. It's a tiny patch, but is worth a 1-2% reduction in bytes-allocated by the compiler. Here's the list, based on the compiler-performance tests in perf/compiler: Reduction in bytes allocated T10858(normal) -0.7% T12425(optasm) -1.3% T13056(optasm) -1.8% T14683(normal) -1.1% T15164(normal) -1.3% T15630(normal) -1.4% T17516(normal) -2.3% T18282(normal) -1.6% T18304(normal) -0.8% T1969(normal) -0.6% T4801(normal) -0.8% T5321FD(normal) -0.7% T5321Fun(normal) -0.5% T5642(normal) -0.9% T6048(optasm) -1.1% T9020(optasm) -2.7% T9233(normal) -0.7% T9675(optasm) -0.5% T9961(normal) -2.9% WWRec(normal) -1.2% Metric Decrease: T12425 T9020 T9961 (cherry picked from commit 3d345c96)
353521ab -
Ben Gamari authored
Previously the Hadrian jobs had the default dependencies, meaning that they would download artifacts from all jobs of earlier stages. This is unneccessary. (cherry picked from commit 57aca6bb)
c0a3283a -
Ben Gamari authored
Hopefully this will make the Windows jobs a bit more reliable. (cherry picked from commit 0a815cea)
e14ee26b -
Simon Peyton Jones authored
Specifically: #13253 exponential inlining #10421 ditto #18140 strict constructors #18282 another nested-function call case This patch makes one really significant changes: change the way that mkDupableCont handles StrictArg. The details are explained in GHC.Core.Opt.Simplify Note [Duplicating StrictArg]. Specific changes * In mkDupableCont, when making auxiliary bindings for the other arguments of a call, add extra plumbing so that we don't forget the demand on them. Otherwise we haev to wait for another round of strictness analysis. But actually all the info is to hand. This change affects: - Make the strictness list in ArgInfo be [Demand] instead of [Bool], and rename it to ai_dmds. - Add as_dmd to ValArg - Simplify.makeTrivial takes a Demand - mkDupableContWithDmds takes a [Demand] There are a number of other small changes 1. For Ids that are used at most once in each branch of a case, make the occurrence analyser record the total number of syntactic occurrences. Previously we recorded just OneBranch or MultipleBranches. I thought this was going to be useful, but I ended up barely using it; see Note [Note [Suppress exponential blowup] in GHC.Core.Opt.Simplify.Utils Actual changes: * See the occ_n_br field of OneOcc. * postInlineUnconditionally 2. I found a small perf buglet in SetLevels; see the new function GHC.Core.Opt.SetLevels.hasFreeJoin 3. Remove the sc_cci field of StrictArg. I found I could get its information from the sc_fun field instead. Less to get wrong! 4. In ArgInfo, arrange that ai_dmds and ai_discs have a simpler invariant: they line up with the value arguments beyond ai_args This allowed a bit of nice refactoring; see isStrictArgInfo, lazyArgcontext, strictArgContext There is virtually no difference in nofib. (The runtime numbers are bogus -- I tried a few manually.) Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- fft +0.0% -2.0% -48.3% -49.4% 0.0% multiplier +0.0% -2.2% -50.3% -50.9% 0.0% -------------------------------------------------------------------------------- Min -0.4% -2.2% -59.2% -60.4% 0.0% Max +0.0% +0.1% +3.3% +4.9% 0.0% Geometric Mean +0.0% -0.0% -33.2% -34.3% -0.0% Test T18282 is an existing example of these deeply-nested strict calls. We get a big decrease in compile time (-85%) because so much less inlining takes place. Metric Decrease: T18282 (cherry picked from commit 0bd60059)
cf9a6c17 -
Before this change make-based `BIGNUM_BACKEND=native` build was failing as: ``` x86_64-pc-linux-gnu-gcc: error: libraries/ghc-bignum/gmp/objs/*.o: No such file or directory ``` This happens because ghc.mk was pulling in gmp-dependent ghc-bignum library unconditionally. The change avoid building ghc-bignum. Bug: #18437 Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org> (cherry picked from commit 39c89862)
6ba13945 -
(cherry picked from commit b9a880fc)
59226e20 -
Simon Peyton Jones authored
They are readily derivable from other fields, so this is more efficient, and less error prone. Fixes #18494 (cherry picked from commit bbc51916)
9166d4d6 -
We now compute the deps for `-fkeep-going` the same way that the original graph calculates them, so the edges are correct. Upsweep really ought to take the graph rather than a topological sort so we are never recalculating anything, but at least things are recaluclated consistently now. (cherry picked from commit 6c68a842)
505a9d68 -
Simon Peyton Jones authored
This tiny patch improves the compile time of flatten-heavy programs by 1-2%, by adding two bangs. Addresses (somewhat) #18502 This reduces allocation by T9872b -1.1% T9872d -3.3% T5321Fun -0.2% T5631 -0.2% T5837 +0.1% T6048 +0.1% Metric Decrease: T9872b T9872d (cherry picked from commit 9f71f697)
bd365c1d -
Sylvain Henry authored
(cherry picked from commit 7c274cd5)
6653e139 -
Fixes #18070 GHC_STAGE is the stage of the compiler we're building, it should be 1,2(,3?). But make was generating 0 and 1. Hadrian does this correctly using a similar `+ 1`: https://gitlab.haskell.org/ghc/ghc/-/blob/eb8115a8c4cbc842b66798480fefc7ab64d31931/hadrian/src/Rules/Generate.hs#L245 (cherry picked from commit f2d1accf)
2c86713b -
In the invocation of `cabal configure`, `--ghc-pkg-option=--global-package-db` was already given correctly to tell `stage0/bin/ghc-pkg` that it should use the package DB in `stage1/`. However, `ghc` needs to be given this information as well, not only `ghc-pkg`! Until now that was not the case; the package DB in `stage0` was given to `ghc` instead. This was wrong, because there is no binary compatibility guarantee that says that the `stage0` DB's `package.cache` (which is written by the stage0 == system-provided ghc-pkg) can be deserialised by the `ghc-pkg` from the source code tree. As a result, when trying to add fields to `InstalledPackageInfo` that get serialised into / deserialised from the `package.cache`, errors like _build/stage0/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!) would appear. This was because the `stage0/bin/ghc would try to deserialise the newly added fields from `_build/stage0/lib/package.conf.d/package.cache`, but they were not in there because the system `ghc-pkg` doesn't know about them and thus didn't write them there. It would try to do that because any GHC by default tries to read the global package db in `../lib/package.conf.d/package.cache`. For `stage0/bin/ghc` that *can never work* as explained above, so we must disable this default via `-no-global-package-db` and give it the correct package DB explicitly. This is the same problem as #16534, and the same fix as in MR !780 (but in another context; that one was for developers trying out the `stage0/bin/ghc` == `_build/ghc-stage1` interactively, while this fix is for a `cabal configure` invocation). I also noticed that the fix for #16534 forgot to pass `-no-global-package-db`, and have fixed that in this commit as well. It only worked until now because nobody tried to add a new ghc-pkg `.conf` field since the introduction of Hadrian. (cherry picked from commit 947206f4)
36d8cd6f -
Ben Gamari authored
This reverts commit 2290eb02. (cherry picked from commit 2bff2f87)
20a45d0c -
Ben Gamari authored
Previously to merge a set of object files we would invoke the linker as usual, adding -r to the command-line. However, this can result in non-sensical command-lines which causes lld to balk (#17962). To avoid this we introduce a new tool setting into GHC, -pgmlm, which is the linker which we use to merge object files. (cherry picked from commit 53ce0db5)
2911d640 -
Ryan Scott authored
The patch is quite straightforward. The only tricky part is that `Language.Haskell.TH.Lib.Internal` now must be `Trustworthy` instead of `Safe` due to the `GHC.Exts` import (in order to import `TYPE`). Since `CodeQ` has yet to appear in any released version of `template-haskell`, I didn't bother mentioning the change to `CodeQ` in the `template-haskell` release notes. Fixes #18521. (cherry picked from commit fbcb886d)
cb3e202a -
Before this patch, NegativeLiterals used to parse x-1 as x (-1). This may not be what the user expects, and now it is fixed: x-1 is parsed as (-) x 1. We achieve this by the following requirement: * When lexing a negative literal, it must not be preceded by a 'closing token'. This also applies to unboxed literals, e.g. -1#. See GHC Proposal #229 for the definition of a closing token. A nice consequence of this change is that -XNegativeLiterals becomes a subset of -XLexicalNegation. In other words, enabling both of those extensions has the same effect as enabling -XLexicalNegation alone. (cherry picked from commit aee45d9e)
bd506bd6 -
GHC 8.12.1 has been renamed to GHC 9.0.1. See also: https://mail.haskell.org/pipermail/ghc-devs/2020-July/019083.html [skip ci] (cherry picked from commit 9570c212)
bc186461 -
Ben Gamari authored
(cherry picked from commit 5f036063)
77653d5c -
Ben Gamari authored
As mentioned in Note [Register parameter passing] the arguments of foreign calls cannot refer to caller-saved registers. (cherry picked from commit 6402c124)
47de152f -
Ben Gamari authored
Previously the code generator could produce corrupt C call sequences due to register overlap between MachOp lowerings and the platform's calling convention. We fix this using a hack described in Note [Evaluate C-call arguments before placing in destination registers]. (cherry picked from commit 15b36de0)
e64ac078 -
Ben Gamari authored
(cherry picked from commit 3847ae0c)
24c230ce -
Ben Gamari authored
Previously it failed as the `ghc` package was not visible. (cherry picked from commit dd51d53b)
ee2ed876 -
Remove unused ApiAnns, add one for linear arrow. Include API Annotations for trailing comma in export list. (cherry picked from commit e4f1b73a)
b4c33250 -
Ben Gamari authored
We want to only run the check if ld is gold. Fixes the fix to #17962. (cherry picked from commit 8a665db6)
cb39cfdc -
(cherry picked from commit ef2ae81a)
b221b571 -
Ben Gamari authored
Previously it collected everything, including "max bytes used". This is problematic since the test makes no attempt to control for deviations in GC timing, resulting in high variability. Fix this by only collecting "bytes allocated". (cherry picked from commit f1088b3f)
c15fb71b -
Ben Gamari authored
(cherry picked from commit bbde6ea0)
3bda53ad -
Ben Gamari authored
(cherry picked from commit 4b91e5ed) Metric Decrease: T13056 T18304 T1969 T9233
ce32390c -
Ben Gamari authored
Previously we had a very aggressive Core Lint check which caught unsaturated applications of runRW#. However, there is nothing wrong with such applications and they may naturally arise in desugared Core. For instance, the desugared Core of Data.Primitive.Array.runArray# from the `primitive` package contains: case ($) (runRW# @_ @_) (\s -> ...) of ... In this case it's almost certain that ($) will be inlined, turning the application into a saturated application. However, even if this weren't the case there isn't a problem: CorePrep (after deleting an unnecessary case) can simply generate code in its usual way, resulting in a call to the Haskell definition of runRW#. Fixes #18291. (cherry picked from commit 2f0bae73)
57fd3ff0 -
Ben Gamari authored
(cherry picked from commit 6c7785f8)
0af2db18 -
Ben Gamari authored
(cherry picked from commit 4f334120c8e9cc4aefcbf11d99f169f648af9fde)
614ac76d -
Ben Gamari authored1a54d708
-
Ben Gamari authored20e19811
-
Ben Gamari authored8c7e8e1c
-
Alan Zimmerman authored93cfed07
-
Alan Zimmerman authored
And prefix ~
3ccc80ee -
Alan Zimmerman authoredf4ad068c
Showing
- .gitlab-ci.yml 25 additions, 45 deletions.gitlab-ci.yml
- .gitlab/ci.sh 7 additions, 0 deletions.gitlab/ci.sh
- .gitlab/test-metrics.sh 5 additions, 0 deletions.gitlab/test-metrics.sh
- CODEOWNERS 15 additions, 0 deletionsCODEOWNERS
- aclocal.m4 133 additions, 8 deletionsaclocal.m4
- compiler/GHC.hs 2 additions, 2 deletionscompiler/GHC.hs
- compiler/GHC/Cmm/CLabel.hs 1 addition, 1 deletioncompiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Lint.hs 35 additions, 5 deletionscompiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/MachOp.hs 3 additions, 0 deletionscompiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Node.hs 7 additions, 6 deletionscompiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Sink.hs 1 addition, 0 deletionscompiler/GHC/Cmm/Sink.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs 92 additions, 8 deletionscompiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Core/Coercion.hs 6 additions, 4 deletionscompiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/DataCon.hs 6 additions, 3 deletionscompiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Lint.hs 15 additions, 35 deletionscompiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/OccurAnal.hs 11 additions, 7 deletionscompiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/Pipeline.hs 1 addition, 1 deletioncompiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Core/Opt/SetLevels.hs 10 additions, 2 deletionscompiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify.hs 233 additions, 170 deletionscompiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Monad.hs 18 additions, 6 deletionscompiler/GHC/Core/Opt/Simplify/Monad.hs