summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* removing x87 register support from native code genCarter Schonwald2019-04-1024-914/+291
| | | | | | | | | | | | | | | | * simplifies registers to have GPR, Float and Double, by removing the SSE2 and X87 Constructors * makes -msse2 assumed/default for x86 platforms, fixing a long standing nondeterminism in rounding behavior in 32bit haskell code * removes the 80bit floating point representation from the supported float sizes * theres still 1 tiny bit of x87 support needed, for handling float and double return values in FFI calls wrt the C ABI on x86_32, but this one piece does not leak into the rest of NCG. * Lots of code thats not been touched in a long time got deleted as a consequence of all of this all in all, this change paves the way towards a lot of future further improvements in how GHC handles floating point computations, along with making the native code gen more accessible to a larger pool of contributors.
* GHC no longer ever defines TABLES_NEXT_TO_CODE on its ownJoachim Breitner2019-04-092-8/+2
| | | | | | | | | | | | | | | It should be entirely the responsibility of make/Hadrian to ensure that everything that needs this flag gets it. GHC shouldn't be hardcoded to assist with bootstrapping since it builds other things besides itself. Reviewers: Subscribers: TerrorJack, rwbarton, carter GHC Trac Issues: #15548 -- progress towards but not fix Differential Revision: https://phabricator.haskell.org/D5082 -- extract from that
* codegen: use newtype for Alignment in BasicTypesArtem Pyanykh2019-04-096-48/+71
|
* codegen: fix memset unroll for small bytearrays, add 64-bit setsArtem Pyanykh2019-04-093-29/+77
| | | | | | | | | | | | | | | | | | | | | | Fixes #16052 When the offset in `setByteArray#` is statically known, we can provide better alignment guarantees then just 1 byte. Also, memset can now do 64-bit wide sets. The current memset intrinsic is not optimal however and can be improved for the case when we know that we deal with (baseAddress at known alignment) + offset For instance, on 64-bit `setByteArray# s 1# 23# 0#` given that bytearray is 8 bytes aligned could be unrolled into `movb, movw, movl, movq, movq`; but currently it is `movb x23` since alignment of 1 is all we can embed into MO_Memset op.
* Make `singleConstructor` cope with pattern synonymsSebastian Graf2019-04-081-53/+92
| | | | | | | | | | | | | | | Previously, `singleConstructor` didn't handle singleton `COMPLETE` sets of a single pattern synonym, resulting in incomplete pattern warnings in #15753. This is fixed by making `singleConstructor` (now named `singleMatchConstructor`) query `allCompleteMatches`, necessarily making it effectful. As a result, most of this patch is concerned with threading the side-effect through to `singleMatchConstructor`. Unfortunately, this is not enough to completely fix the original reproduction from #15753 and #15884, which are related to function applications in pattern guards being translated too conservatively.
* Add `-optcxx` option (#16477)Yuriy Syrovetskiy2019-04-087-20/+49
|
* Fix #16500: look for interface files in -hidir flag in OneShot modePhuong Trinh2019-04-081-2/+13
| | | | | | | | | | | We are currently ignoring options set in the hiDir field of hsc_dflags when looking for interface files while compiling in OneShot mode. This is inconsistent with the behaviour of other directory redirecting fields (such as objectDir or hieDir). It is also inconsistent with the behaviour of compilation in CompManager mode (a.k.a `ghc --make`) which looks for interface files in the directory set in hidir flag. This changes Finder.hs so that we use the value of hiDir while looking for interface in OneShot mode.
* Generate straightline code for inline array allocationMichal Terepeta2019-04-081-11/+5
| | | | | | | | | | | | | | | GHC has an optimization for allocating arrays when the size is statically known -- it'll generate the code allocating and initializing the array inline (instead of a call to a procedure from `rts/PrimOps.cmm`). However, the generated code uses a loop to do the initialization. Since we already check that the requested size is small (we check against `maxInlineAllocSize`), we can generate faster straightline code instead. This brings about 15% improvement for `newSmallArray#` in my testing and slightly simplifies the code in GHC. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
* Fix #16282.Eric Crockett2019-04-072-24/+31
| | | | | | | Previously, -W(all-)missed-specs was created with 'NoReason', so no information about the flag was printed along with the warning. Now, -Wall-missed-specs is listed as the Reason if it was set, otherwise -Wmissed-specs is listed as the reason.
* Tweak error messages for narrowly-kinded assoc default declsRyan Scott2019-04-041-24/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This program, from #13971, currently has a rather confusing error message: ```hs class C a where type T a :: k type T a = Int ``` ``` • Kind mis-match on LHS of default declaration for ‘T’ • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ ``` It's not at all obvious why GHC is complaining about the LHS until you realize that the default, when printed with `-fprint-explicit-kinds`, is actually `type T @{k} @* a = Int`. That is to say, the kind of `a` is being instantiated to `Type`, whereas it ought to be a kind variable. The primary thrust of this patch is to weak the error message to make this connection more obvious: ``` • Illegal argument ‘*’ in: ‘type T @{k} @* a = Int’ The arguments to ‘T’ must all be type variables • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ ``` Along the way, I performed some code cleanup suggested by @rae in https://gitlab.haskell.org/ghc/ghc/issues/13971#note_191287. Before, we were creating a substitution from the default declaration's type variables to the type family tycon's type variables by way of `tcMatchTys`. But this is overkill, since we already know (from the aforementioned validity checking) that all the arguments in a default declaration must be type variables anyway. Therefore, creating the substitution is as simple as using `zipTvSubst`. I took the opportunity to perform this refactoring while I was in town. Fixes #13971.
* Use funPrec, not topPrec, to parenthesize GADT argument typesRyan Scott2019-04-041-8/+13
| | | | A simple oversight. Fixes #16527.
* Fix #16518 with some more kind-splitting smartsRyan Scott2019-04-042-16/+38
| | | | | | | | | | | | | | | | This patch corrects two simple oversights that led to #16518: 1. `HsUtils.typeToLHsType` was taking visibility into account in the `TyConApp` case, but not the `AppTy` case. I've factored out the visibility-related logic into its own `go_app` function and now invoke `go_app` from both the `TyConApp` and `AppTy` cases. 2. `Type.fun_kind_arg_flags` did not properly split kinds with nested `forall`s, such as `(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply because `fun_kind_arg_flags`'s `FunTy` case always bailed out and assumed all subsequent arguments were `Required`, which clearly isn't the case for nested `forall`s. I tweaked the `FunTy` case to recur on the result kind.
* Fix Uncovered set of literal patternsSebastian Graf2019-04-032-5/+14
| | | | | | | | | | | | | | | | Issues #16289 and #15713 are proof that the pattern match checker did an unsound job of estimating the value set abstraction corresponding to the uncovered set. The reason is that the fix from #11303 introducing `NLit` was incomplete: The `LitCon` case desugared to `Var` rather than `LitVar`, which would have done the necessary case splitting analogous to the `ConVar` case. This patch rectifies that by introducing the fresh unification variable in `LitCon` in value abstraction position rather than pattern postition, recording a constraint equating it to the constructor expression rather than the literal. Fixes #16289 and #15713.
* Correct two misspellings of "separately"Chris Martin2019-04-031-1/+1
|
* Fix faulty substitutions in StgCse (#11532).klebinger.andreas@gmx.at2019-04-031-2/+2
| | | | | | | | | | | | `substBndr` should rename bindings which shadow existing ids. However while it was renaming the bindings it was not adding proper substitutions for renamed bindings. Instead of adding a substitution of the form `old -> new` for renamed bindings it mistakenly added `old -> old` if no replacement had taken place while adding none if `old` had been renamed. As a byproduct this should improve performance, as we no longer add useless substitutions for unshadowed bindings.
* Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)Michael Sloan2019-04-015-5/+4
| | | | Also removes a couple unnecessary MagicHash pragmas
* Add support for bitreverse primopAlexandre2019-04-019-5/+50
| | | | | | This commit includes the necessary changes in code and documentation to support a primop that reverses a word's bits. It also includes a test.
* Visibility: handle multiple units with the same nameMichael Peyton Jones2019-03-291-13/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #16228. The included test case is adapted from the reproduction in the issue, and fails without this patch. ------ We compute an initial visilibity mapping for units based on what is present in the package databases. To seed this, we compute a set of all the package configs to add visibilities for. However, this set was keyed off the unit's *package name*. This is correct, since we compare packages across databases by version. However, we would only ever consider a single, most-preferable unit from the database in which it was found. The effect of this was that only one of the libraries in a Cabal package would be added to this initial set. This would cause attempts to use modules from the omitted libraries to fail, claiming that the package was hidden (even though `ghc-pkg` would correctly show it as visible). A solution is to do the selection of the most preferable packages separately, and then be sure to consider exposing all units in the same package in the same package db. We can do this by picking a most-preferable unit for each package name, and then considering exposing all units that are equi-preferable with that unit. ------ Why wasn't this bug apparent to all people trying to use sub-libraries in Cabal? The answer is that Cabal explicitly passes `-package` and `-package-id` flags for all the packages it wants to use, rather than relying on the state of the package database. So this bug only really affects people who are trying to use package databases produced by Cabal outside of Cabal itself. One particular example of this is the way that the Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these are equipped with a package database containing all the needed package dependencies, and the user is not expected to pass `-package` flags explicitly.
* Fix a few broken Trac links [skip ci]Chaitanya Koparkar2019-03-271-1/+1
| | | | This patch only attempts to fix links that don't automatically re-direct to the correct URL.
* Minor refactoring in copy array primops:Ömer Sinan Ağacan2019-03-271-15/+17
| | | | | | | | | | - `emitCopySmallArray` now checks size before generating code and doesn't generate any code when size is 0. `emitCopyArray` already does this so this makes small/large array cases the same in argument checking. - In both `emitCopySmallArray` and `emitCopyArray` read the `dflags` after checking the argument.
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-2545-61/+61
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-03-227-117/+26
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Remove unused XArrApp and XArrForm extension pointsRyan Scott2019-03-202-9/+0
| | | | | | !301 removed the `HsArrApp` and `HsArrForm` constructors, which renders the corresponding extension points `XArrApp` and `XArrForm` useless. This patch finally rips them out.
* Check.hs: Fix a few typosSimon Jakobi2019-03-201-5/+5
|
* Reject nested predicates in impredicativity checkingRyan Scott2019-03-202-41/+45
| | | | | | | | | | | | | | | | | | | | | | | | | When GHC attempts to unify a metavariable with a type containing foralls, it will be rejected as an occurrence of impredicativity. GHC was /not/ extending the same treatment to predicate types, such as in the following (erroneous) example from #11514: ```haskell foo :: forall a. (Show a => a -> a) -> () foo = undefined ``` This will attempt to instantiate `undefined` at `(Show a => a -> a) -> ()`, which is impredicative. This patch catches impredicativity arising from predicates in this fashion. Since GHC is pickier about impredicative instantiations, some test cases needed to be updated to be updated so as not to fall afoul of the new validity check. (There were a surprising number of impredicative uses of `undefined`!) Moreover, the `T14828` test case now has slightly less informative types shown with `:print`. This is due to a a much deeper issue with the GHCi debugger (see #14828). Fixes #11514.
* Remove deprecated reinitializeGlobalsKrzysztof Gogolewski2019-03-191-7/+0
|
* Simplify monadic codeKrzysztof Gogolewski2019-03-192-13/+10
|
* Fix typosKrzysztof Gogolewski2019-03-196-7/+7
|
* Replace nOfThem by replicateKrzysztof Gogolewski2019-03-196-15/+12
|
* ghc-heap: Introduce closureSizeBen Gamari2019-03-171-0/+7
| | | | | | This function allows the user to compute the (non-transitive) size of a heap object in words. The "closure" in the name is admittedly confusing but we are stuck with this nomenclature at this point.
* compiler: Disable atomic renaming on WindowsBen Gamari2019-03-161-1/+13
| | | | | As discussed in #16450, this feature regresses CI on Windows, causing non-deterministic failures due to missing files.
* Add location to the extra-constraints wildcardSimon Peyton Jones2019-03-161-3/+4
| | | | | | | The extra-constraints wildcard had lost its location (issue #16431). Happily this is easy to fix. Lots of error improvements.
* Improve error recovery in the typecheckerSimon Peyton Jones2019-03-168-178/+264
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue #16418 showed that we were carrying on too eagerly after a bogus type signature was identified (a bad telescope in fact), leading to a subsequent crash. This led me in to a maze of twisty little passages in the typechecker's error recovery, and I ended up doing some refactoring in TcRnMonad. Some specfifics * TcRnMonad.try_m is now called attemptM. * I switched the order of the result pair in tryTc, to make it consistent with other similar functions. * The actual exception used in the Tc monad is irrelevant so, to avoid polluting type signatures, I made tcTryM, a simple wrapper around tryM, and used it. The more important changes are in * TcSimplify.captureTopConstraints, where we should have been calling simplifyTop rather than reportUnsolved, so that levity defaulting takes place properly. * TcUnify.emitResidualTvConstraint, where we need to set the correct status for a new implication constraint. (Previously we ended up with an Insoluble constraint wrapped in an Unsolved implication, which meant that insolubleWC gave the wrong answer.
* PPC NCG: Use liveness information in CmmCallPeter Trommler2019-03-154-42/+49
| | | | | | | | | | | | | | | | | We make liveness information for global registers available on `JMP` and `BCTR`, which were the last instructions missing. With complete liveness information we do not need to reserve global registers in `freeReg` anymore. Moreover we assign R9 and R10 to callee saves registers. Cleanup by removing `Reg_Su`, which was unused, from `freeReg` and removing unused register definitions. The calculation of the number of floating point registers is too conservative. Just follow X86 and specify the constants directly. Overall on PowerPC this results in 0.3 % smaller code size in nofib while runtime is slightly better in some tests.
* Report better suggestion for GADT data constructorSimon Peyton Jones2019-03-151-13/+9
| | | | This addresses issue #16427. An easy fix.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-15166-850/+850
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Remove the GHCi debugger's panicking isUnliftedType checkRyan Scott2019-03-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GHCi debugger has never been that robust in the face of higher-rank types, or even types that are _interally_ higher-rank, such as the types of many class methods (e.g., `fmap`). In GHC 8.2, however, things became even worse, as the debugger would start to _panic_ when a user tries passing the name of a higher-rank thing to `:print`. This all ties back to a strange `isUnliftedType` check in `Debugger` that was mysteriously added 11 years ago (in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no explanation whatsoever. After some experimentation, no one is quite sure what this `isUnliftedType` check is actually accomplishing. The test suite still passes if it's removed, and I am unable to observe any differences in debugger before even with data types that _do_ have fields of unlifted types (e.g., `data T = MkT Int#`). Given that this is actively causing problems (see #14828), the prudent thing to do seems to be just removing this `isUnliftedType` check, and waiting to see if anyone shouts about it. This patch accomplishes just that. Note that this patch fix the underlying issues behind #14828, as the debugger will still print unhelpful info if you try this: ``` λ> f :: (forall a. a -> a) -> b -> b; f g x = g x λ> :print f f = (_t1::t1) ``` But fixing this will require much more work, so let's start with the simple stuff for now.
* Fix #16411 by making dataConCannotMatch aware of (~~)Ryan Scott2019-03-131-4/+7
| | | | | | | | The `dataConCannotMatch` function (which powers the `-Wpartial-fields` warning, among other things) had special reasoning for explicit equality constraints of the form `a ~ b`, but it did not extend that reasoning to `a ~~ b` constraints, leading to #16411. Easily fixed.
* Remove duplicate functions in StgCmmUtils, use functions from CgUtilsÖmer Sinan Ağacan2019-03-122-51/+11
| | | | Also remove unused arg from get_Regtable_addr_from_offset
* Use transSuperClasses in TcErrorsSimon Peyton Jones2019-03-122-12/+31
| | | | | | | | | | Code in TcErrors was recursively using immSuperClasses, which loops in the presence of UndecidableSuperClasses. Better to use transSuperClasses instead, which has a loop-breaker mechanism built in. Fixes issue #16414.
* Change the warning in substTy back to an assertionKrzysztof Gogolewski2019-03-114-6/+5
| | | | | | | We'd like to enforce the substitution invariant (Trac #11371). In a492af06d326453 the assertion was downgraded to a warning; I'm restoring the assertion and making the calls that don't maintain the invariant as unchecked.
* NCG: correctly escape path strings on Windows (#16389)Sylvain Henry2019-03-093-3/+15
| | | | | GHC native code generator generates .incbin and .file directives. We need to escape those strings correctly on Windows (see #16389).
* compiler: Refactor: extract `withAtomicRename`Niklas Hambüchen2019-03-092-8/+29
|
* compiler: Write .o files atomically. See #14533Niklas Hambüchen2019-03-091-1/+6
| | | | | | | | | | | | | | | | | | | This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com> Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
* Stop inferring over-polymorphic kindsSimon Peyton Jones2019-03-097-109/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch GHC was trying to be too clever (Trac #16344); it succeeded in kind-checking this polymorphic-recursive declaration data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) As Note [No polymorphic recursion] discusses, the "solution" was horribly fragile. So this patch deletes the key lines in TcHsType, and a wodge of supporting stuff in the renamer. There were two regressions, both the same: a closed type family decl like this (T12785b) does not have a CUSK: type family Payload (n :: Peano) (s :: HTree n x) where Payload Z (Point a) = a Payload (S n) (a `Branch` stru) = a To kind-check the equations we need a dependent kind for Payload, and we don't get that any more. Solution: make it a CUSK by giving the result kind -- probably a good thing anyway. The other case (T12442) was very similar: a close type family declaration without a CUSK.
* Fix #13839: GHCi warnings do not respect the default module headerwip/magic-carpet-rideRoland Senn2019-03-081-4/+34
|
* TH: support raw bytes literals (#14741)Sylvain Henry2019-03-082-0/+22
| | | | | | | | | | | | | | | | | | | GHC represents String literals as ByteString internally for efficiency reasons. However, until now it wasn't possible to efficiently create large string literals with TH (e.g. to embed a file in a binary, cf #14741): TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack into a ByteString. This patch adds the possibility to efficiently create a "string" literal from raw bytes. We get the following compile times for different sizes of TH created literals: || Size || Before || After || Gain || || 30K || 2.307s || 2.299 || 0% || || 3M || 3.073s || 2.400s || 21% || || 30M || 8.517s || 3.390s || 60% || Ticket #14741 can be fixed if the original code uses this new TH feature.
* Use captureTopConstraints in TcRnDriver callsSimon Peyton Jones2019-03-083-10/+28
| | | | | | | | | | | | | | | | | Trac #16376 showed the danger of failing to report an error that exists only in the unsolved constraints, if an exception is raised (via failM). Well, the commit 5c1f268e (Fail fast in solveLocalEqualities) did just that -- i.e. it found errors in the constraints, and called failM to avoid a misleading cascade. So we need to be sure to call captureTopConstraints to report those insolubles. This was wrong in TcRnDriver.tcRnExpr and in TcRnDriver.tcRnType. As a result the error messages from test T13466 improved slightly, a happy outcome.
* Always do the worker/wrapper split for NOINLINEsSebastian Graf2019-03-072-7/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #10069 revealed that small NOINLINE functions didn't get split into worker and wrapper. This was due to `certainlyWillInline` saying that any unfoldings with a guidance of `UnfWhen` inline unconditionally. That isn't the case for NOINLINE functions, so we catch this case earlier now. Nofib results: -------------------------------------------------------------------------------- Program Allocs Instrs -------------------------------------------------------------------------------- fannkuch-redux -0.3% 0.0% gg +0.0% +0.1% maillist -0.2% -0.2% minimax 0.0% -0.8% -------------------------------------------------------------------------------- Min -0.3% -0.8% Max +0.0% +0.1% Geometric Mean -0.0% -0.0% Fixes #10069. ------------------------- Metric Increase: T9233 -------------------------
* Fix #16391 by using occCheckExpand in TcValidityRyan Scott2019-03-074-26/+88
| | | | | | | | | | | | | The type-variables-escaping-their-scope-via-kinds check in `TcValidity` was failing to properly expand type synonyms, which led to #16391. This is easily fixed by using `occCheckExpand` before performing the validity check. Along the way, I refactored this check out into its own function, and sprinkled references to Notes to better explain all of the moving parts. Many thanks to @simonpj for the suggestions. Bumps the haddock submodule.
View Lorry Controller Status