summaryrefslogtreecommitdiff
path: root/compiler/ghc.cabal.in
Commit message (Collapse)AuthorAgeFilesLines
* base: Bump version to 4.14.0.0Ben Gamari2019-11-141-1/+1
| | | | | Metric Increase: T4801
* Ensure that coreView/tcView are able to inlineBen Gamari2019-11-131-1/+0
| | | | | | | | | | | | | | | | | | | | Previously an import cycle between Type and TyCoRep meant that several functions in TyCoRep ended up SOURCE import coreView. This is quite unfortunate as coreView is intended to be fused into a larger pattern match and not incur an extra call. Fix this with a bit of restructuring: * Move the functions in `TyCoRep` which depend upon things in `Type` into `Type` * Fold contents of `Kind` into `Type` and turn `Kind` into a simple wrapper re-exporting kind-ish things from `Type` * Clean up the redundant imports that popped up as a result Closes #17441. Metric Decrease: T4334
* Implement s390x LLVM backend.Stefan Schulze Frielinghaus2019-10-221-0/+1
| | | | | | This patch adds support for the s390x architecture for the LLVM code generator. The patch includes a register mapping of STG registers onto s390x machine registers which enables a registerised build.
* Break up TcRnTypes, among other modules.Richard Eisenberg2019-10-161-0/+3
| | | | | | | | | | | | | | | | | | | | | This introduces three new modules: - basicTypes/Predicate.hs describes predicates, moving this logic out of Type. Predicates don't really exist in Core, and so don't belong in Type. - typecheck/TcOrigin.hs describes the origin of constraints and types. It was easy to remove from other modules and can often be imported instead of other, scarier modules. - typecheck/Constraint.hs describes constraints as used in the solver. It is taken from TcRnTypes. No work other than module splitting is in this patch. This is the first step toward homogeneous equality, which will rely more strongly on predicates. And homogeneous equality is the next step toward a dependently typed core language.
* Add loop level analysis to the NCG backend.klebinger.andreas@gmx.at2019-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | For backends maintaining the CFG during codegen we can now find loops and their nesting level. This is based on the Cmm CFG and dominator analysis. As a result we can estimate edge frequencies a lot better for methods, resulting in far better code layout. Speedup on nofib: ~1.5% Increase in compile times: ~1.9% To make this feasible this commit adds: * Dominator analysis based on the Lengauer-Tarjan Algorithm. * An algorithm estimating global edge frequences from branch probabilities - In CFG.hs A few static branch prediction heuristics: * Expect to take the backedge in loops. * Expect to take the branch NOT exiting a loop. * Expect integer vs constant comparisons to be false. We also treat heap/stack checks special for branch prediction to avoid them being treated as loops.
* Always enable the external interpreterJohn Ericson2019-10-041-11/+0
| | | | | | You can always just not use or even build `iserv`. I don't think the maintenance cost of the CPP is worth...I can't even tell what the benefit is.
* Pull out the settings file parsing code into it's own module.John Ericson2019-10-041-0/+1
| | | | | | | | | | | This has two benefits: 1. One less hunk of code dependent on DynFlags 2. Add a little bit of error granularity to distrinugish between missing data and bad data. This could someday be shared with ghc-pkg which aims to work even with a missing file. I also am about to to make --supported-extensions use this too.
* Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.hJohn Ericson2019-10-041-1/+1
| | | | | | | | | | | | | | | | | | The generated headers are now generated per stage, which means we can skip hacks like `ghc_boot_platform.h` and just have that be the stage 0 header as proper. In general, stages are to be embraced: freely generate everything in each stage but then just build what you depend on, and everything is symmetrical and efficient. Trying to avoid stages because bootstrapping is a mind bender just creates tons of bespoke mini-mind-benders that add up to something far crazier. Hadrian was pretty close to this "stage-major" approach already, and so was fairly easy to fix. Make needed more work, however: it did know about stages so at least there was a scaffold, but few packages except for the compiler cared, and the compiler used its own counting system. That said, make and Hadrian now work more similarly, which is good for the transition to Hadrian. The merits of embracing stage aside, the change may be worthy for easing that transition alone.
* Merge TcTypeableValidity into TcTypeable, document treatment of castsRyan Scott2019-10-031-1/+0
| | | | | | | | | | | | | | | This patch: * Implements a refactoring (suggested in https://gitlab.haskell.org/ghc/ghc/merge_requests/1199#note_207345) that moves all functions from `TcTypeableValidity` back to `TcTypeable`, as the former module doesn't really need to live on its own. * Adds `Note [Typeable instances for casted types]` to `TcTypeable` explaining why the `Typeable` solver currently does not support types containing casts. Resolves #16835.
* Move pattern match checker modules to GHC.HsToCore.PmCheckSebastian Graf2019-09-301-4/+4
|
* Module hierarchy: Hs (#13009)Sylvain Henry2019-09-201-16/+15
| | | | | | | Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
* Extract PmTypes module from PmExpr and PmOracleSebastian Graf2019-09-191-2/+2
| | | | | | | | | | | Apparently ghc-lib-parser's API blew up because the newly induced cyclic dependency between TcRnTypes and PmOracle pulled in the other half of GHC into the relevant strongly-connected component. This patch arranges it so that PmTypes exposes mostly data type definitions and type class instances to be used within PmOracle, without importing the any of the possibly offending modules DsMonad, TcSimplify and FamInst.
* Encode shape information in `PmOracle`Sebastian Graf2019-09-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we had an elaborate mechanism for selecting the warnings to generate in the presence of different `COMPLETE` matching groups that, albeit finely-tuned, produced wrong results from an end user's perspective in some cases (#13363). The underlying issue is that at the point where the `ConVar` case has to commit to a particular `COMPLETE` group, there's not enough information to do so and the status quo was to just enumerate all possible complete sets nondeterministically. The `getResult` function would then pick the outcome according to metrics defined in accordance to the user's guide. But crucially, it lacked knowledge about the order in which affected clauses appear, leading to the surprising behavior in #13363. In !1010 we taught the term oracle to reason about literal values a variable can certainly not take on. This MR extends that idea to `ConLike`s and thereby fixes #13363: Instead of committing to a particular `COMPLETE` group in the `ConVar` case, we now split off the matching constructor incrementally and record the newly covered case as a refutable shape in the oracle. Whenever the set of refutable shapes covers any `COMPLETE` set, the oracle recognises vacuosity of the uncovered set. This patch goes a step further: Since at this point the information in value abstractions is merely a cut down representation of what the oracle knows, value abstractions degenerate to a single `Id`, the semantics of which is determined by the oracle state `Delta`. Value vectors become lists of `[Id]` given meaning to by a single `Delta`, value set abstractions (of which the uncovered set is an instance) correspond to a union of `Delta`s which instantiate the same `[Id]` (akin to models of formula). Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149 ------------------------- Metric Decrease: ManyAlternatives T11195 -------------------------
* Rename GHC.StgToCmm.Con -> GHC.StgToCmm.DataConBen Gamari2019-09-151-1/+1
| | | | | | | | | Incredibly, Windows disallows the manipulation of any file matching Con(\..*)?. The `GHC.StgToCmm.Con` was introduced in the renamings in 447864a9, breaking the Windows build. Work around this by renaming it to `GHC.StgToCmm.DataCon` Fixes #17187.
* Module hierarchy: StgToCmm (#13009)Sylvain Henry2019-09-101-27/+27
| | | | | | Add StgToCmm module hierarchy. Platform modules that are used in several other places (NCG, LLVM codegen, Cmm transformations) are put into GHC.Platform.
* Break up TyCoRepBen Gamari2019-07-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | This breaks up the monstrous TyCoReps module into several new modules by topic: * TyCoRep: Contains the `Coercion`, `Type`, and related type definitions and a few simple predicates but nothing further * TyCoPpr: Contains the the pretty-printer logic * TyCoFVs: Contains the free variable computations (and `tyConAppNeedsKindSig`, although I suspect this should change) * TyCoSubst: Contains the substitution logic for types and coercions * TyCoTidy: Contains the tidying logic for types While we are able to eliminate a good number of `SOURCE` imports (and make a few others smaller) with this change, we must introduce one new `hs-boot` file for `TyCoPpr` so that `TyCoRep` can define `Outputable` instances for the types it defines. Metric Increase: haddock.Cabal haddock.compiler
* Expose the GhcPrelude module.Andreas Klebinger2019-07-211-3/+1
| | | | | | | | | | This makes it simpler to load Modules importing it when using ghc-the-package. ------------------------- Metric Decrease: haddock.compiler -------------------------
* Bump template-haskell version to 2.16.0.0Ryan Scott2019-07-031-1/+1
| | | | | | | Commit cef80c0b9edca3d21b5c762f51dfbab4c5857d8a debuted a breaking change to `template-haskell`, so in order to guard against it properly with CPP, we need to bump the `template-haskell` version number accordingly.
* Add HoleFitPlugins and RawHoleFitswip/D5373Matthías Páll Gissurarson2019-06-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new kind of plugin, Hole fit plugins. These plugins can change what candidates are considered when looking for valid hole fits, and add hole fits of their own. The type of a plugin is relatively simple, ``` type FitPlugin = TypedHole -> [HoleFit] -> TcM [HoleFit] type CandPlugin = TypedHole -> [HoleFitCandidate] -> TcM [HoleFitCandidate] data HoleFitPlugin = HoleFitPlugin { candPlugin :: CandPlugin , fitPlugin :: FitPlugin } data TypedHole = TyH { tyHRelevantCts :: Cts -- ^ Any relevant Cts to the hole , tyHImplics :: [Implication] -- ^ The nested implications of the hole with the -- innermost implication first. , tyHCt :: Maybe Ct -- ^ The hole constraint itself, if available. } This allows users and plugin writers to interact with the candidates and fits as they wish, even going as far as to allow them to reimplement the current functionality (since `TypedHole` contains all the relevant information). As an example, consider the following plugin: ``` module HolePlugin where import GhcPlugins import TcHoleErrors import Data.List (intersect, stripPrefix) import RdrName (importSpecModule) import TcRnTypes import System.Process plugin :: Plugin plugin = defaultPlugin { holeFitPlugin = hfp, pluginRecompile = purePlugin } hfp :: [CommandLineOption] -> Maybe HoleFitPluginR hfp opts = Just (fromPureHFPlugin $ HoleFitPlugin (candP opts) (fp opts)) toFilter :: Maybe String -> Maybe String toFilter = flip (>>=) (stripPrefix "_module_") replace :: Eq a => a -> a -> [a] -> [a] replace match repl str = replace' [] str where replace' sofar (x:xs) | x == match = replace' (repl:sofar) xs replace' sofar (x:xs) = replace' (x:sofar) xs replace' sofar [] = reverse sofar -- | This candidate plugin filters the candidates by module, -- using the name of the hole as module to search in candP :: [CommandLineOption] -> CandPlugin candP _ hole cands = do let he = case tyHCt hole of Just (CHoleCan _ h) -> Just (occNameString $ holeOcc h) _ -> Nothing case toFilter he of Just undscModName -> do let replaced = replace '_' '.' undscModName let res = filter (greNotInOpts [replaced]) cands return $ res _ -> return cands where greNotInOpts opts (GreHFCand gre) = not $ null $ intersect (inScopeVia gre) opts greNotInOpts _ _ = True inScopeVia = map (moduleNameString . importSpecModule) . gre_imp -- Yes, it's pretty hacky, but it is just an example :) searchHoogle :: String -> IO [String] searchHoogle ty = lines <$> (readProcess "hoogle" [(show ty)] []) fp :: [CommandLineOption] -> FitPlugin fp ("hoogle":[]) hole hfs = do dflags <- getDynFlags let tyString = showSDoc dflags . ppr . ctPred <$> tyHCt hole res <- case tyString of Just ty -> liftIO $ searchHoogle ty _ -> return [] return $ (take 2 $ map (RawHoleFit . text . ("Hoogle says: " ++)) res) ++ hfs fp _ _ hfs = return hfs ``` with this plugin available, you can compile the following file ``` {-# OPTIONS -fplugin=HolePlugin -fplugin-opt=HolePlugin:hoogle #-} module Main where import Prelude hiding (head, last) import Data.List (head, last) t :: [Int] -> Int t = _module_Prelude g :: [Int] -> Int g = _module_Data_List main :: IO () main = print $ t [1,2,3] ``` and get the following output: ``` Main.hs:14:5: error: • Found hole: _module_Prelude :: [Int] -> Int Or perhaps ‘_module_Prelude’ is mis-spelled, or not in scope • In the expression: _module_Prelude In an equation for ‘t’: t = _module_Prelude • Relevant bindings include t :: [Int] -> Int (bound at Main.hs:14:1) Valid hole fits include Hoogle says: GHC.List length :: [a] -> Int Hoogle says: GHC.OldList length :: [a] -> Int t :: [Int] -> Int (bound at Main.hs:14:1) g :: [Int] -> Int (bound at Main.hs:17:1) length :: forall (t :: * -> *) a. Foldable t => t a -> Int with length @[] @Int (imported from ‘Prelude’ at Main.hs:5:1-34 (and originally defined in ‘Data.Foldable’)) maximum :: forall (t :: * -> *) a. (Foldable t, Ord a) => t a -> a with maximum @[] @Int (imported from ‘Prelude’ at Main.hs:5:1-34 (and originally defined in ‘Data.Foldable’)) (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits) | 14 | t = _module_Prelude | ^^^^^^^^^^^^^^^ Main.hs:17:5: error: • Found hole: _module_Data_List :: [Int] -> Int Or perhaps ‘_module_Data_List’ is mis-spelled, or not in scope • In the expression: _module_Data_List In an equation for ‘g’: g = _module_Data_List • Relevant bindings include g :: [Int] -> Int (bound at Main.hs:17:1) Valid hole fits include Hoogle says: GHC.List length :: [a] -> Int Hoogle says: GHC.OldList length :: [a] -> Int g :: [Int] -> Int (bound at Main.hs:17:1) head :: forall a. [a] -> a with head @Int (imported from ‘Data.List’ at Main.hs:7:19-22 (and originally defined in ‘GHC.List’)) last :: forall a. [a] -> a with last @Int (imported from ‘Data.List’ at Main.hs:7:25-28 (and originally defined in ‘GHC.List’)) | 17 | g = _module_Data_List ``` This relatively simple plugin has two functions, as an example of what is possible to do with hole fit plugins. The candidate plugin starts by filtering the candidates considered by module, indicated by the name of the hole (`_module_Data_List`). The second function is in the fit plugin, where the plugin invokes a local hoogle instance to search by the type of the hole. By adding the `RawHoleFit` type, we can also allow these completely free suggestions, used in the plugin above to display fits found by Hoogle. Additionally, the `HoleFitPluginR` wrapper can be used for plugins to maintain state between invocations, which can be used to speed up invocation of plugins that have expensive initialization. ``` -- | HoleFitPluginR adds a TcRef to hole fit plugins so that plugins can -- track internal state. Note the existential quantification, ensuring that -- the state cannot be modified from outside the plugin. data HoleFitPluginR = forall s. HoleFitPluginR { hfPluginInit :: TcM (TcRef s) -- ^ Initializes the TcRef to be passed to the plugin , hfPluginRun :: TcRef s -> HoleFitPlugin -- ^ The function defining the plugin itself , hfPluginStop :: TcRef s -> TcM () -- ^ Cleanup of state, guaranteed to be called even on error } ``` Of course, the syntax here is up for debate, but hole fit plugins allow us to experiment relatively easily with ways to interact with typed-holes without having to dig deep into GHC. Reviewers: bgamari Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5373
* Move 'Platform' to ghc-bootJohn Ericson2019-06-191-1/+0
| | | | | | | ghc-pkg needs to be aware of platforms so it can figure out which subdire within the user package db to use. This is admittedly roundabout, but maybe Cabal could use the same notion of a platform as GHC to good affect too.
* Synchronize ClsInst.doTyConApp with TcTypeable validity checks (#15862)Ryan Scott2019-06-151-0/+1
| | | | | | | | | | | | | | | | | Issue #15862 demonstrated examples of type constructors on which `TcTypeable.tyConIsTypeable` would return `False`, but the `Typeable` constraint solver in `ClsInst` (in particular, `doTyConApp`) would try to generate `Typeable` evidence for anyway, resulting in disaster. This incongruity was caused by the fact that `doTyConApp` was using a weaker validity check than `tyConIsTypeable` to determine if a type constructor warrants `Typeable` evidence or not. The solution, perhaps unsurprisingly, is to use `tyConIsTypeable` in `doTyConApp` instead. To avoid import cycles between `ClsInst` and `TcTypeable`, I factored out `tyConIsTypeable` into its own module, `TcTypeableValidity`. Fixes #15862.
* Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETERAlp Mestanogullari2019-06-111-1/+12
| | | | | | | | | | | | | | | | | As discussed in #16331, the GHCI macro, defined through 'ghci' flags in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate whether GHC is built with support for an internal interpreter, that runs in the same process. It is however overloaded in a few places to mean "there is an interpreter available", regardless of whether it's an internal or external interpreter. For the sake of clarity and with the hope of more easily being able to build stage 1 GHCs with external interpreter support, this patch splits the previous GHCI macro into 3 different ones: - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
* TmOracle: Replace negative term equalities by refutable PmAltConsSebastian Graf2019-06-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The `PmExprEq` business was a huge hack and was at the same time vastly too powerful and not powerful enough to encode negative term equalities, i.e. facts of the form "forall y. x ≁ Just y". This patch introduces the concept of 'refutable shapes': What matters for the pattern match checker is being able to encode knowledge of the kind "x can no longer be the literal 5". We encode this knowledge in a `PmRefutEnv`, mapping a set of newly introduced `PmAltCon`s (which are just `PmLit`s at the moment) to each variable denoting above inequalities. So, say we have `x ≁ 42 ∈ refuts` in the term oracle context and try to solve an equality like `x ~ 42`. The entry in the refutable environment will immediately lead to a contradiction. This machinery renders the whole `PmExprEq` and `ComplexEq` business unnecessary, getting rid of a lot of (mostly dead) code. See the Note [Refutable shapes] in TmOracle for a place to start. Metric Decrease: T11195
* Break up `Settings` into smaller structsJohn Ericson2019-05-291-0/+5
| | | | | | | | | | | | | | | | | As far as I can tell, the fields within `Settings` aren't *intrinsicly* related. They just happen to be initialized the same way (in particular prior to the rest of `DynFlags`), and that is why they are grouped together. Within `Settings`, however, there are groups of settings that clearly do share something in common, regardless of how they anything is initialized. In the spirit of GHC being a library, where the end cosumer may choose to initialize this configuration in arbitrary ways, I made some new data types for thoses groups internal to `Settings`, and used them to define `Settings` instead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC.
* Add PlainPanic for throwing exceptions without depending on pprintMichael Sloan2019-05-241-0/+1
| | | | | | | | | | | | | | | | | | | | | This commit splits out a subset of GhcException which do not depend on pretty printing (SDoc), as a new datatype called PlainGhcException. These exceptions can be caught as GhcException, because 'fromException' will convert them. The motivation for this change is that that the Panic module transitively depends on many modules, primarily due to pretty printing code. It's on the order of about 130 modules. This large set of dependencies has a few implications: 1. To avoid cycles / use of boot files, these dependencies cannot throw GhcException. 2. There are some utility modules that use UnboxedTuples and also use `panic`. This means that when loading GHC into GHCi, about 130 additional modules would need to be compiled instead of interpreted. Splitting the non-pprint exception throwing into a new module resolves this issue. See #13101
* Allow for multiple linker instances. Fixes Haskell portion of #3372.Julian Leviston2019-05-211-0/+1
|
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-03-221-1/+0
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Prepare source-tree for base-4.13 MFP bumpHerbert Valerio Riedel2019-01-181-1/+1
|
* Support printing `integer-simple` Integers in GHCiAlec Theriault2019-01-161-0/+14
| | | | | | | | | | This means that `:p` no longer leaks the implementation details of `Integer` with `integer-simple`. The `print037` test case should exercise all possible code paths for GHCi's code around printing `Integer`s (both in `integer-simple` and `integer-gmp`). `ghc` the package now also has a Cabal `integer-simple` flag (like the `integer-gmp` one).
* PPC NCG: Remove Darwin supportPeter Trommler2019-01-011-1/+0
| | | | | | | Support for Mac OS X on PowerPC has been dropped by Apple years ago. We follow suit and remove PowerPC support for Darwin. Fixes #16106.
* Support generating HIE filesAlec Theriault2018-12-111-0/+6
| | | | | | | | | | | | | | | | | | | | Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie` files (see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/HIEFiles). This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for his GSOC project, as posted here: https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d. Test Plan: ./validate Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi Reviewed By: alanz, sjakobi Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter Differential Revision: https://phabricator.haskell.org/D5239
* Implement late lambda liftSebastian Graf2018-11-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This implements a selective lambda-lifting pass late in the STG pipeline. Lambda lifting has the effect of avoiding closure allocation at the cost of having to make former free vars available at call sites, possibly enlarging closures surrounding call sites in turn. We identify beneficial cases by means of an analysis that estimates closure growth. There's a Wiki page at https://ghc.haskell.org/trac/ghc/wiki/LateLamLift. Reviewers: simonpj, bgamari, simonmar Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #9476 Differential Revision: https://phabricator.haskell.org/D5224
* Don't track free variables in STG syntax by defaultSebastian Graf2018-11-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, `CoreToStg` annotates `StgRhsClosure`s with their set of non-global free variables. This free variable information is only needed in the final code generation step (i.e. `StgCmm.codeGen`), which leads to transformations such as `StgCse` and `StgUnarise` having to maintain this information. This is tiresome and unnecessary, so this patch introduces a trees-to-grow-like approach that only introduces the free variable set into the syntax tree in the code gen pass, along with a free variable analysis on STG terms to generate that information. Fixes #15754. Reviewers: simonpj, osa1, bgamari, simonmar Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #15754 Differential Revision: https://phabricator.haskell.org/D5324
* NCG: New code layout algorithm.Andreas Klebinger2018-11-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a new code layout algorithm. It has been tested for x86 and is disabled on other platforms. Performance varies slightly be CPU/Machine but in general seems to be better by around 2%. Nofib shows only small differences of about +/- ~0.5% overall depending on flags/machine performance in other benchmarks improved significantly. Other benchmarks includes at least the benchmarks of: aeson, vector, megaparsec, attoparsec, containers, text and xeno. While the magnitude of gains differed three different CPUs where tested with all getting faster although to differing degrees. I tested: Sandy Bridge(Xeon), Haswell, Skylake * Library benchmark results summarized: * containers: ~1.5% faster * aeson: ~2% faster * megaparsec: ~2-5% faster * xml library benchmarks: 0.2%-1.1% faster * vector-benchmarks: 1-4% faster * text: 5.5% faster On average GHC compile times go down, as GHC compiled with the new layout is faster than the overhead introduced by using the new layout algorithm, Things this patch does: * Move code responsilbe for block layout in it's own module. * Move the NcgImpl Class into the NCGMonad module. * Extract a control flow graph from the input cmm. * Update this cfg to keep it in sync with changes during asm codegen. This has been tested on x64 but should work on x86. Other platforms still use the old codelayout. * Assign weights to the edges in the CFG based on type and limited static analysis which are then used for block layout. * Once we have the final code layout eliminate some redundant jumps. In particular turn a sequences of: jne .foo jmp .bar foo: into je bar foo: .. Test Plan: ci Reviewers: bgamari, jmct, jrtc27, simonmar, simonpj, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, trommler, jmct, carter, thomie, rwbarton GHC Trac Issues: #15124 Differential Revision: https://phabricator.haskell.org/D4726
* Bump time submoduleBen Gamari2018-11-021-1/+1
|
* Bump template-haskell version to 2.15.0.0Ryan Scott2018-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, `th-abstraction`). This properly bumps the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15818 Differential Revision: https://phabricator.haskell.org/D5272
* Bump binary submodule to 0.8.6.0Ben Gamari2018-08-071-1/+1
| | | | | This is actually a decrease in the version number since a bump to 0.10 wasn't actually necessary.
* Bump binary submoduleBen Gamari2018-08-031-1/+1
|
* Support the GHCi debugger with -fexternal-interpreterSimon Marlow2018-07-161-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * All the tests in tests/ghci.debugger now pass with -fexternal-interpreter. These tests are now run with the ghci-ext way in addition to the normal way so we won't break it in the future. * I removed all the unsafeCoerce# calls from RtClosureInspect. Yay! The main changes are: * New messages: GetClosure and Seq. GetClosure is a remote interface to GHC.Exts.Heap.getClosureData, which required Binary instances for various datatypes. Fortunately this wasn't too painful thanks to DeriveGeneric. * No cheating by unsafeCoercing values when printing them. Now we have to turn the Closure representation back into the native representation when printing Int, Float, Double, Integer and Char. Of these, Integer was the most painful - we now have a dependency on integer-gmp due to needing access to the representation. * Fixed a bug in rts/Heap.c - it was bogusly returning stack content as pointers for an AP_STACK closure. Test Plan: * `cd testsuite/tests/ghci.debugger && make` * validate Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter GHC Trac Issues: #13184 Differential Revision: https://phabricator.haskell.org/D4955
* Refactor validity checking for constraintsSimon Peyton Jones2018-07-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several changes here. * TcInteract has gotten too big, so I moved all the class-instance matching out of TcInteract into a new module ClsInst. It parallels the FamInst module. The main export of ClsInst is matchGlobalInst. This now works in TcM not TcS. * A big reason to make matchGlobalInst work in TcM is that we can then use it from TcValidity.checkSimplifiableClassConstraint. That extends checkSimplifiableClassConstraint to work uniformly for built-in instances, which means that we now get a warning if we have givens (Typeable x, KnownNat n); see Trac #15322. * This change also made me refactor LookupInstResult, in particular by adding the InstanceWhat field. I also changed the name of the type to ClsInstResult. Then instead of matchGlobalInst reporting a staging error (which is inappropriate for the call from TcValidity), we can do so in TcInteract.checkInstanceOK. * In TcValidity, we now check quantified constraints for termination. For example, this signature should be rejected: f :: (forall a. Eq (m a) => Eq (m a)) => blah as discussed in Trac #15316. The main change here is that TcValidity.check_pred_help now uses classifyPredType, and has a case for ForAllPred which it didn't before. This had knock-on refactoring effects in TcValidity.
* containers: Bump to 0.6.0.1Ben Gamari2018-06-201-1/+1
| | | | Bumps containers submodule, among others.
* Revert "containers: Bump to 0.6.0.1"Ben Gamari2018-06-191-1/+1
| | | | | | | | This reverts commit 50e7bff7514ebbd74976c1a9fa0db7a8275178ae. Reverts submodule changes. Sigh, the haskeline commit isn't quite upstream yet.
* containers: Bump to 0.6.0.1Ben Gamari2018-06-191-1/+1
| | | | Bumps containers submodule, among others.
* Serialize docstrings to ifaces, display them with new GHCi :doc commandSimon Jakobi2018-06-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | If `-haddock` is set, we now extract docstrings from the renamed ast and serialize them in the .hi-files. This includes some of the changes from D4749 with the notable exceptions of the docstring lexing and renaming. A currently limited and experimental GHCi :doc command can be used to display docstrings for declarations. The formatting of pretty-printed docstrings is changed slightly, causing some changes in testsuite/tests/haddock. Test Plan: ./validate Reviewers: alexbiehl, hvr, gershomb, harpocrates, bgamari Reviewed By: alexbiehl Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4758
* vectorise: Put it out of its miseryBen Gamari2018-06-021-30/+0
| | | | | | | | | | | | | | | | | | | | | Poor DPH and its vectoriser have long been languishing; sadly it seems there is little chance that the effort will be rekindled. Every few years we discuss what to do with this mass of code and at least once we have agreed that it should be archived on a branch and removed from `master`. Here we do just that, eliminating heaps of dead code in the process. Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and `primitive` submodules. Test Plan: Validate Reviewers: simonpj, simonmar, hvr, goldfire, alanz Reviewed By: simonmar Subscribers: goldfire, rwbarton, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4761
* Improved Valid Hole FitsMatthías Páll Gissurarson2018-05-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've changed the name from `Valid substitutions` to `Valid hole fits`, since "substitution" already has a well defined meaning within the theory. As part of this change, the flags and output is reanamed, with substitution turning into hole-fit in most cases. "hole fit" was already used internally in the code, it's clear and shouldn't cause any confusion. In this update, I've also reworked how we manage side-effects in the hole we are considering. This allows us to consider local bindings such as where clauses and arguments to functions, suggesting e.g. `a` for `head (x:xs) where head :: [a] -> a`. It also allows us to find suggestions such as `maximum` for holes of type `Ord a => a -> [a]`, and `max` when looking for a match for the hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`. We also show much improved output for refinement hole fits, and fixes #14990. We now show the correct type of the function, but we also now show what the arguments to the function should be e.g. `foldl1 (_ :: Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`. I've moved the bulk of the code from `TcErrors.hs` to a new file, `TcHoleErrors.hs`, since it was getting too big to not live on it's own. This addresses the considerations raised in #14969, and takes proper care to set the `tcLevel` of the variables to the right level before passing it to the simplifier. We now also zonk the suggestions properly, which improves the output of the refinement hole fits considerably. This also filters out suggestions from the `GHC.Err` module, since even though `error` and `undefined` are indeed valid hole fits, they are "trivial", and almost never useful to the user. We now find the hole fits using the proper manner, namely by solving nested implications. This entails that the givens are passed along using the implications the hole was nested in, which in turn should mean that there will be fewer weird bugs in the typed holes. I've also added a new sorting method (as suggested by SPJ) and sort by the size of the types needed to turn the hole fits into the type of the hole. This gives a reasonable approximation to relevance, and is much faster than the subsumption check. I've also added a flag to toggle whether to use this new sorting algorithm (as is done by default) or the subsumption algorithm. This fixes #14969 I've also added documentation for these new flags and update the documentation according to the new output. Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14969, #14990, #10946 Differential Revision: https://phabricator.haskell.org/D4444
* Add HeapView functionalityPatrick Dougherty2018-05-201-1/+1
| | | | | | | | | | | | | | | | | | | | | This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC. The bits added are the C hooks into the RTS and a basic Haskell wrapper to these C hooks. The main reason for these to be added to GHC proper is that the code needs to be kept in sync with the closure types defined by the RTS. It is expected that the version of HeapView shipped with GHC will always work with that version of GHC and that extra functionality can be layered on top with a library like ghc-heap-view distributed via Hackage. Test Plan: validate Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd Reviewed By: bgamari Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3055
* Split TrieMap into a general (TrieMap) and core specific (CoreTrieMap) module.klebinger.andreas@gmx.at2018-05-051-0/+1
| | | | | | | | | | | | | | | | | | Splitting TrieMap into a general and core specific part allows us to define instances for TrieMap without creating a transitive dependency on CoreSyn. Test Plan: ci Reviewers: goldfire, bgamari, simonmar, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, nomeata, thomie, carter GHC Trac Issues: #15082 Differential Revision: https://phabricator.haskell.org/D4618
* Bump unix submodule to version 2.8.0.0Ryan Scott2018-04-191-1/+1
| | | | | | | | | | | | | | Summary: Requires bumping several submodules. Test Plan: ./validate Reviewers: hvr, bgamari Subscribers: thomie, carter GHC Trac Issues: #15042 Differential Revision: https://phabricator.haskell.org/D4604
* TTG for HsBinds and Data instances Plan BAlan Zimmerman2018-04-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Add the balance of the TTG extensions for hsSyn/HsBinds - Move all the (now orphan) data instances into hsSyn/HsInstances and use TTG Data instances Plan B https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB Updates haddock submodule. Illustrative numbers Compiling HsInstances before using Plan B. Max residency ~ 5G <<ghc: 629,864,691,176 bytes, 5300 GCs, 321075437/1087762592 avg/max bytes residency (23 samples), 2953M in use, 0.000 INIT (0.000 elapsed), 383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>> Using Plan B Max residency 1.1G <<ghc: 78,832,782,968 bytes, 2884 GCs, 222140352/386470152 avg/max bytes residency (34 samples), 1062M in use, 0.001 INIT (0.001 elapsed), 56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>> Test Plan: ./validate Reviewers: shayan-najd, goldfire, bgamari Subscribers: goldfire, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4581
View Lorry Controller Status