summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Bump Cabal submodule to 3.6.3.0wip/bump-cabal-9.2Ben Gamari2022-03-031-0/+0
|
* testsuite: Specify expected word-size of machop testswip/aarch64-9.2Ben Gamari2022-03-021-7/+8
| | | | | | These generally expect a particular word size. (cherry picked from commit 44c088631f2d14f25c9cefeee174db4576b4c5cc)
* CmmToC: Cast possibly-signed results as unsignedBen Gamari2022-03-021-10/+40
| | | | | | | | | C11 rule 6.3.1.1 dictates that all small integers used in expressions be implicitly converted to `signed int`. However, Cmm semantics require that the width of the operands be preserved with zero-extension semantics. For this reason we must recast sub-word arithmetic results as unsigned. (cherry picked from commit e98dad1bcd09e13988056310655c62b2afa512be)
* CmmToC: Always cast arguments as unsignedBen Gamari2022-03-024-4/+33
| | | | | | | | | As noted in Note [When in doubt, cast arguments as unsigned], we must ensure that arguments have the correct signedness since some operations (e.g. `%`) have different semantics depending upon signedness. (cherry picked from commit 0aeaa8f35025d49bbb85c867a86baf23330d17a1)
* CmmToC: Zero-extend sub-word size resultsBen Gamari2022-03-021-6/+41
| | | | | | | As noted in Note [Zero-extending sub-word signed results] we must explicitly zero-extend the results of sub-word-sized signed operations. (cherry picked from commit ebaf7333b83b8838de138105337962623c0c6239)
* CmmToC: Fix width of shift operationsBen Gamari2022-03-021-3/+15
| | | | | | | Under C's implicit widening rules, the result of an operation like (a >> b) where a::Word8 and b::Word will have type Word, yet we want Word. (cherry picked from commit e19e9e71739ffd01d6557256b59b3bd26651a4ad)
* nativeGen/aarch64: Fix handling of subword valuesBen Gamari2022-03-023-83/+228
| | | | | | | | | | | | | | | | | | Here we rework the handling of sub-word operations in the AArch64 backend, fixing a number of bugs and inconsistencies. In short, we now impose the invariant that all subword values are represented in registers in zero-extended form. Signed arithmetic operations are then responsible for sign-extending as necessary. Possible future work: * Use `CMP`s extended register form to avoid burning an instruction in sign-extending the second operand. * Track sign-extension state of registers to elide redundant sign extensions in blocks with frequent sub-word signed arithmetic. (cherry picked from commit adc7f108141a973b6dcb02a7836eed65d61230e8)
* [aarch64 NCG] Add better support for sub-word primopsMoritz Angermann2022-03-023-35/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the intial NCG development, GHC did not have support for anything below Words. As such the NCG didn't support any of this either. AArch64-Darwin however needs support for subword, as arguments in excess of the first eight (8) passed via registers are passed on the stack, and there in a packed fashion. Thus ghc learned about subword sizes. This than lead us to gain subword primops, and these subsequently highlighted deficiencies in the AArch64 NCG. This patch rectifies the ones I found through via the test-suite. I do not claim this to be exhaustive. Fixes: #19993 Metric Increase: T10421 T13035 T13719 T14697 T1969 T9203 T9872a T9872b T9872c T9872d T9961 haddock.Cabal haddock.base parsing001 (cherry picked from commit d79530d17bc9de61a8bda58308c0377d1c3c697b)
* cmm/opt: Fold away shifts larger than shiftee widthBen Gamari2022-03-021-2/+12
| | | | | | | This is necessary for lint-correctness since we no longer allow such shifts in Cmm. (cherry picked from commit 9c65197e0aec9a4ee11e377dac52f459ac64067a)
* nativeGen/aarch64: Don't rely on register width to determine amodeBen Gamari2022-03-021-13/+20
| | | | | | | We might be loading, e.g., a 16- or 8-bit value, in which case the register width is not reflective of the loaded element size. (cherry picked from commit 7094f4faeb78a3ffda98c44700b4addba3f5b951)
* testsuite: Add testcases for various machop issuesBen Gamari2022-03-0211-0/+72
| | | | | | There were found by the test-primops testsuite. (cherry picked from commit 2f6565cf5edd1d8b2d95f7c97d5875c05939c0ed)
* cmm: Disallow shifts larger than shifteeBen Gamari2022-03-022-0/+19
| | | | | | | | | | | | | | Previously primops.txt.pp stipulated that the word-size shift primops were only defined for shift offsets in [0, word_size). However, there was no further guidance for the definition of Cmm's sub-word size shift MachOps. Here we fix this by explicitly disallowing (checked in many cases by CmmLint) shift operations where the shift offset is larger than the shiftee. This is consistent with LLVM's shift operations, avoiding the miscompilation noted in #20637. (cherry picked from commit 35bbc251b5b0b1292b1335ad2aed349e8a5b79d1)
* ncg/aarch64: Don't sign extend loadsBen Gamari2022-03-021-2/+2
| | | | | | | Previously we would emit the sign-extending LDS[HB] instructions for sub-word loads. However, this is wrong, as noted in #20638. (cherry picked from commit 78b78ac463b0b8aad688edcea3c4af447854b929)
* cmm: narrow when folding signed quotientsBen Gamari2022-03-021-2/+2
| | | | | | | | | | | | | | | | | | | Previously the constant-folding behavior for MO_S_Quot and MO_S_Rem failed to narrow its arguments, meaning that a program like: %zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8)) would be miscompiled. Specifically, this program should reduce as %lobits8(0x00e1::bits16) == -31 %quot(%lobits8(0x00e1::bits16), 3::bits8) == -10 %zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8)) == 246 However, with this bug the `%lobits8(0x00e1::bits16)` would instead be treated as `+31`, resulting in the incorrect result of `75`. (cherry picked from commit 94e197e3dbb9a48991eb90a03b51ea13d39ba4cc) (cherry picked from commit 5b950a7f939a35538abf61ea8e86ddd07cc75237)
* nativeGen/x86: Don't encode large shift offsetsBen Gamari2022-03-021-1/+10
| | | | | | | | | | | | Handle the case of a shift larger than the width of the shifted value. This is necessary since x86 applies a mask of 0x1f to the shift amount, meaning that, e.g., `shr 47, $eax` will actually shift by 47 & 0x1f == 15. See #20626. (cherry picked from commit 31370f1afe1e2f071b3569fb5ed4a115096127ca) (cherry picked from commit 1724ac37633b2796e2410296e8a34bc8e1fa4934)
* gitlab-ci: Use integer-simple in alpine release jobBen Gamari2022-03-021-0/+1
|
* simplCore: Correctly extend in-scope set in rule matchingBen Gamari2022-02-251-27/+50
| | | | | | | | | | | | | | | | | | Note [Matching lets] in GHC.Core.Rules claims the following: > We use GHC.Core.Subst.substBind to freshen the binding, using an > in-scope set that is the original in-scope variables plus the > rs_bndrs (currently floated let-bindings). However, previously the implementation didn't actually do extend the in-scope set with rs_bndrs. This appears to be a regression which was introduced by 4ff4d434e9a90623afce00b43e2a5a1ccbdb4c05. Moreover, the originally reasoning was subtly wrong: we must rather use the in-scope set from rv_lcl, extended with rs_bndrs, not that of `rv_fltR` Fixes #21122.
* Revert "simplCore: Correctly extend in-scope set in rule matching"Ben Gamari2022-02-251-1/+1
| | | | This reverts commit 8bbdba450980c2b0054e19ae737eeaa3cfdb452d.
* Accept perf shiftsBen Gamari2022-02-230-0/+0
| | | | | | | | Metric Decrease: T9872c Metric Increase: T12545 T18223
* simplCore: Correctly extend in-scope set in rule matchingBen Gamari2022-02-231-1/+1
| | | | | | | | | | | | | | | | | | Note [Matching lets] in GHC.Core.Rules claims the following: > We use GHC.Core.Subst.substBind to freshen the binding, using an > in-scope set that is the original in-scope variables plus the > rs_bndrs (currently floated let-bindings). However, previously the implementation didn't actually do extend the in-scope set with rs_bndrs. This appears to be a regression which was introduced by 4ff4d434e9a90623afce00b43e2a5a1ccbdb4c05. Reintroduce `rs_bndrs` into the in-scope set, ensuring that let-binders cannot shadow one another due to rule rewrites. Fixes #21122. (cherry picked from commit 0f7dc6701cfb6be59deb8601da8da000fe70263f)
* Extend the in-scope set to silence substExpr warningsSimon Peyton Jones2022-02-231-2/+12
| | | | | | | | substExpr warns if it finds a LocalId that isn't in the in-scope set. This patch extends the in-scope set to silence the warnings. (It has no effect on behaviour.) (cherry picked from commit 25ca0b5aef54281d161288d9d951a6325d0ab53f)
* Make RULE matching insensitive to eta-expansionSimon Peyton Jones2022-02-2313-214/+565
| | | | | | | | | | | | This patch fixes #19790 by making the rule matcher do on-the-fly eta reduction. See Note [Eta reduction the target] in GHC.Core.Rules I found I also had to careful about casts when matching; see Note [Casts in the target] and Note [Casts in the template] Lots more comments and Notes in the rule matcher (cherry picked from commit 590a2918d815edd184a1665e361640a29674cbf3)
* Get the in-scope set right during RULE matchingSimon Peyton Jones2022-02-235-34/+28
| | | | | | | | | | | | | | | There was a subtle error in the in-scope set during RULE matching, which led to #20200 (not the original report, but the reports of failures following an initial bug-fix commit). This patch fixes the problem, and simplifies the code a bit. In pariticular there was a very mysterious and ad-hoc in-scope set extension in rnMatchBndr2, which is now moved to the right place, namely in the Let case of match, where we do the floating. I don't have a small repro case, alas. (cherry picked from commit 4ff4d434e9a90623afce00b43e2a5a1ccbdb4c05)
* Use the right InScopeSet for findBestSimon Peyton Jones2022-02-233-22/+30
| | | | | | | | | | | This is the right thing to do, easy to do, and fixes a second not-in-scope crash in #20200 (see !6302) The problem occurs in the findBest test, which compares two RULES. Repro case in simplCore/should_compile/T20200a (cherry picked from commit 7f217429a44747e418af6549606fcbcce005ba2e)
* Fix lookupIdSubst call during RULE matchingKrzysztof Gogolewski2022-02-234-13/+27
| | | | | | | | | | | | | As #20200 showed, there was a call to lookupIdSubst during RULE matching, where the variable being looked up wasn't in the InScopeSet. This patch fixes the problem at source, by dealing separately with nested and non-nested binders. As a result we can change the trace call in lookupIdSubst to a proper panic -- if it happens, we really want to know. (cherry picked from commit 149bce42fc324863c5da8c98b4991358b5ec4617)
* Fix a subtle scoping error in simplLazyBindSimon Peyton Jones2022-02-221-10/+15
| | | | | | | | | | | | | | | | | | | | In the call to prepareBinding (in simplLazyBind), I had failed to extend the in-scope set with the binders from body_floats1. As as result, when eta-expanding deep inside prepareBinding we made up an eta-binder that shadowed a variable free in body1. Yikes. It's hard to trigger this bug. It showed up when I was working on !5658, and I started using the in-scope set for eta-expansion, rather than taking free variables afresh. But even then it only showed up when compiling a module in Haddock utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs Sadly Haddock is compiled without Core Lint, so we ultimately got a seg-fault. Lint nailed it fast once I realised that it was off. There is some other tiny refactoring in this patch. (cherry picked from commit 91eb18570fae4e1982e660f6dcb4f7b69de58cf2)
* Simplify and improve the eta expansion mechanismSimon Peyton Jones2022-02-223-155/+151
| | | | | | | | | | | | | Previously the eta-expansion would return lambdas interspersed with casts; now the cast is just pushed to the outside: #20153. This actually simplifies the code. I also improved mkNthCo to account for SymCo, so that mkNthCo n (SymCo (TyConAppCo tc cos)) would work well. (cherry picked from commit a199d653a621fdc96e811c8ae076414965dc25dc)
* Introduce checkReflexiveMCoBen Gamari2022-02-221-1/+6
| | | | A partial backport of 299b7436d140a5f43ce75a2a1d022572f23fb3f9.
* Flip some bits (directions of coercions in rewriting)Richard Eisenberg2022-02-211-4/+4
|
* Add a regression test for #17723sheaf2022-02-214-0/+32
| | | | | | The underlying bug was fixed by b8d98827, see MR !2477 (cherry picked from commit 48b0f17acff0c35df2d3b63dd6b624832cd54852)
* Compare FunTys as if they were TyConApps.Richard Eisenberg2022-02-2111-78/+228
| | | | | | | | | | | | | See Note [Equality on FunTys] in TyCoRep. Close #17675. Close #17655, about documentation improvements included in this patch. Close #19677, about a further mistake around FunTy. test cases: typecheck/should_compile/T19677 (cherry picked from commit b8d98827d73fd3e49867cab09f9440fc8c311bfe)
* Fix Int64ToInt/Word64ToWord rules on 32-bit architecturesSylvain Henry2022-02-192-16/+17
| | | | | | | | When the input literal was larger than 32-bit it would crash in a compiler with assertion enabled because it was creating an out-of-bound word-sized literal (32-bit). (cherry-picked from 4c86df25d3)
* Don't expose bignum backend in ghc --info (#20495)Sylvain Henry2022-02-173-3/+0
| | | | | | | | | GHC is bignum backend agnostic and shouldn't report this information as in the future ghc-bignum will be reinstallable potentially with a different backend that GHC is unaware of. Moreover as #20495 shows the returned information may be wrong currently. (cherry picked from commit 79a26df1475505ee1e87eb7fda04e5fefdf6aa4c)
* Bump Haddock submodule to current ghc-9.2 headBen Gamari2022-02-171-0/+0
| | | | As requested in #20580.
* RTS: open timerfd synchronously (#20618)Sylvain Henry2022-02-171-19/+32
| | | | (cherry picked from commit 2929850f0139778c579fc7144831c88e11353a9b)
* Bump base version to 4.16.1.0Ben Gamari2022-02-1713-22/+22
|
* Update base changelogBen Gamari2022-02-151-1/+3
|
* Fix LLVM version rangeBen Gamari2022-02-151-1/+1
|
* Update autoconf scriptsBen Gamari2022-02-152-606/+760
| | | | Scripts taken from autoconf c179db1b6f2ae484bfca1e9f8bae273e3319fa7d
* Bump parsec 3.1.15.0Ben Gamari2022-02-151-0/+0
|
* Bump filepath to 1.4.2.2Ben Gamari2022-02-151-0/+0
|
* Bump deepseq to 1.4.6.1Ben Gamari2022-02-151-0/+0
|
* Bump Cabal submodule to 3.6.2.0Ben Gamari2022-02-152-1/+1
| | | | Due to #20874.
* users-guide: Write release notes for 9.2.2Ben Gamari2022-02-121-2/+158
|
* Look through untyped TH splices in tcInferAppHead_maybeRyan Scott2022-02-114-7/+37
| | | | | | | | | | | | | Previously, surrounding a head expression with a TH splice would defeat `tcInferAppHead_maybe`, preventing some expressions from typechecking that used to typecheck in previous GHC versions (see #21038 for examples). This is simple enough to fix: just look through `HsSpliceE`s in `tcInferAppHead_maybe`. I've added some additional prose to `Note [Application chains and heads]` in `GHC.Tc.Gen.App` to accompany this change. Fixes #21038. (cherry picked from commit fd9981e347144ce69f4747bd635789f25b673f93)
* Introduce predicate for when to enable source notes (needSourceNotes)Matthew Pickering2022-02-114-8/+10
| | | | | | | | | | There were situations where we were using debugLevel == 0 as a proxy for whether to retain source notes but -finfo-table-map also enables and needs source notes so we should act consistently in both cases. Ticket #20847 (cherry picked from commit 1316f7dadf0f538f09f8b97629c7e5f6f868266d)
* Add the Ix class to Foreign C integral typesHécate Moonlight2022-02-115-3/+13
| | | | | | Related CLC proposal is here: https://github.com/haskell/core-libraries-committee/issues/30 (cherry picked from commit 4bd52410d03f851f69f85d43855358733d5ceb6d)
* Use SrcSpan from the binder as initial source estimateMatthew Pickering2022-02-111-1/+8
| | | | | | | | | | | | | | There are some situations where we end up with no source notes in useful positions in an expression. In this case we currently fail to provide any source information about where an expression came from. This patch improves the initial estimate by using the position from the top-binder as the guess for the location of the whole inner expression. It provides quite a course estimate but it's better than nothing. Ticket #20847 (cherry picked from commit a98e55e767764cb810833492b898d1e75f93fd77)
* Backport !5478 to GHC-9.2 to fix #19460Roland Senn2022-02-1121-236/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | In the master branch !5478 fixed #19460. As #19460 has highest priority and didn't get fixed in the ghc-92 branch, backport MR !5478 to GHC 9.2. Add test T19460. MR !5478: Always generate ModDetails from ModIface This vastly reduces memory usage when compiling with `--make` mode, from about 900M when compiling Cabal to about 300M. As a matter of uniformity, it also ensures that reading from an interface performs the same as using the in-memory cache. We can also delete all the horrible knot-tying in updateIdInfos. Goes some way to fixing #13586 Accept new output of tests fixing some bugs along the way ------------------------- Metric Decrease: T12545 ------------------------- (cherry picked from commit 14e53b1bbe611b46b82f8a917cab49cf489151a5)
* ci: Add missing release jobsMatthew Pickering2022-02-101-13/+13
|
View Lorry Controller Status