summaryrefslogtreecommitdiff
path: root/compiler/GHC
Commit message (Collapse)AuthorAgeFilesLines
* Remove dangling references to Note [Type-checking overloaded labels]Joachim Breitner2022-01-071-6/+4
| | | | that note was removed in 4196969c53c55191e644d9eb258c14c2bc8467da
* Thoughtful forcing in CoreUnfoldingMatthew Pickering2022-01-071-5/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We noticed that the structure of CoreUnfolding could leave double the amount of CoreExprs which were retained in the situation where the template but not all the predicates were forced. This observation was then confirmed using ghc-debug: ``` (["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 237) (["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1) (["ghc:GHC.Core:Case","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 12) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 1) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 78) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","ghc-prim:GHC.Types:False","THUNK_1_0"],Count 1) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 3) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0"],Count 1) (["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 31) (["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 4307) (["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 6) (["ghc:GHC.Core:Let","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 29) (["ghc:GHC.Core:Lit","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1) (["ghc:GHC.Core:Tick","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 36) (["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 1) (["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 6) (["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","ghc-prim:GHC.Types:True","THUNK_1_0"],Count 2) ``` Where we can see that the first argument is forced but there are still thunks remaining which retain the old expr. For my test case (a very big module, peak of 3 000 000 core terms) this reduced peak memory usage by 1G (12G -> 11G). Fixes #20905
* Use primOpIds cache more often (#20857)Sylvain Henry2022-01-0610-89/+119
| | | | | | | | Use primOpId instead of mkPrimOpId in a few places to benefit from Id caching. I had to mess a little bit with the module hierarchy to fix cycles and to avoid adding too many new dependencies to count-deps tests.
* Perf: use SmallArray for primops' Ids cache (#20857)Sylvain Henry2022-01-062-9/+109
| | | | | | SmallArray doesn't perform bounds check (faster). Make primop tags start at 0 to avoid index arithmetic.
* Check quoted TH names are in the correct namespacesheaf2022-01-046-14/+82
| | | | | | | | | | | | When quoting (using a TH single or double quote) a built-in name such as the list constructor (:), we didn't always check that the resulting 'Name' was in the correct namespace. This patch adds a check in GHC.Rename.Splice to ensure we get a Name that is in the term-level/type-level namespace, when using a single/double tick, respectively. Fixes #20884.
* Skip computing superclass origins for equalitiesRichard Eisenberg2021-12-281-4/+13
| | | | This yields a small, but measurable, performance improvement.
* Multiple Home UnitsMatthew Pickering2021-12-2852-1085/+2110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multiple home units allows you to load different packages which may depend on each other into one GHC session. This will allow both GHCi and HLS to support multi component projects more naturally. Public Interface ~~~~~~~~~~~~~~~~ In order to specify multiple units, the -unit @⟨filename⟩ flag is given multiple times with a response file containing the arguments for each unit. The response file contains a newline separated list of arguments. ``` ghc -unit @unitLibCore -unit @unitLib ``` where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode. ``` -this-unit-id lib-core-0.1.0.0 -i -isrc LibCore.Utils LibCore.Types ``` The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core. ``` -this-unit-id lib-0.1.0.0 -package-id lib-core-0.1.0.0 -i -isrc Lib.Parse Lib.Render ``` Then when the compiler starts in --make mode it will compile both units lib and lib-core. There is also very basic support for multiple home units in GHCi, at the moment you can start a GHCi session with multiple units but only the :reload is supported. Most commands in GHCi assume a single home unit, and so it is additional work to work out how to modify the interface to support multiple loaded home units. Options used when working with Multiple Home Units There are a few extra flags which have been introduced specifically for working with multiple home units. The flags allow a home unit to pretend it’s more like an installed package, for example, specifying the package name, module visibility and reexported modules. -working-dir ⟨dir⟩ It is common to assume that a package is compiled in the directory where its cabal file resides. Thus, all paths used in the compiler are assumed to be relative to this directory. When there are multiple home units the compiler is often not operating in the standard directory and instead where the cabal.project file is located. In this case the -working-dir option can be passed which specifies the path from the current directory to the directory the unit assumes to be it’s root, normally the directory which contains the cabal file. When the flag is passed, any relative paths used by the compiler are offset by the working directory. Notably this includes -i and -I⟨dir⟩ flags. -this-package-name ⟨name⟩ This flag papers over the awkward interaction of the PackageImports and multiple home units. When using PackageImports you can specify the name of the package in an import to disambiguate between modules which appear in multiple packages with the same name. This flag allows a home unit to be given a package name so that you can also disambiguate between multiple home units which provide modules with the same name. -hidden-module ⟨module name⟩ This flag can be supplied multiple times in order to specify which modules in a home unit should not be visible outside of the unit it belongs to. The main use of this flag is to be able to recreate the difference between an exposed and hidden module for installed packages. -reexported-module ⟨module name⟩ This flag can be supplied multiple times in order to specify which modules are not defined in a unit but should be reexported. The effect is that other units will see this module as if it was defined in this unit. The use of this flag is to be able to replicate the reexported modules feature of packages with multiple home units. Offsetting Paths in Template Haskell splices ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When using Template Haskell to embed files into your program, traditionally the paths have been interpreted relative to the directory where the .cabal file resides. This causes problems for multiple home units as we are compiling many different libraries at once which have .cabal files in different directories. For this purpose we have introduced a way to query the value of the -working-dir flag to the Template Haskell API. By using this function we can implement a makeRelativeToProject function which offsets a path which is relative to the original project root by the value of -working-dir. ``` import Language.Haskell.TH.Syntax ( makeRelativeToProject ) foo = $(makeRelativeToProject "./relative/path" >>= embedFile) ``` > If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units. A similar function already exists in the file-embed library. The function in template-haskell implements this function in a more robust manner by honouring the -working-dir flag rather than searching the file system. Closure Property for Home Units ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For tools or libraries using the API there is one very important closure property which must be adhered to: > Any dependency which is not a home unit must not (transitively) depend on a home unit. For example, if you have three packages p, q and r, then if p depends on q which depends on r then it is illegal to load both p and r as home units but not q, because q is a dependency of the home unit p which depends on another home unit r. If you are using GHC by the command line then this property is checked, but if you are using the API then you need to check this property yourself. If you get it wrong you will probably get some very confusing errors about overlapping instances. Limitations of Multiple Home Units ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are a few limitations of the initial implementation which will be smoothed out on user demand. * Package thinning/renaming syntax is not supported * More complicated reexports/renaming are not yet supported. * It’s more common to run into existing linker bugs when loading a large number of packages in a session (for example #20674, #20689) * Backpack is not yet supported when using multiple home units. * Dependency chasing can be quite slow with a large number of modules and packages. * Loading wired-in packages as home units is currently not supported (this only really affects GHC developers attempting to load template-haskell). * Barely any normal GHCi features are supported, it would be good to support enough for ghcid to work correctly. Despite these limitations, the implementation works already for nearly all packages. It has been testing on large dependency closures, including the whole of head.hackage which is a total of 4784 modules from 452 packages. Internal Changes ~~~~~~~~~~~~~~~~ * The biggest change is that the HomePackageTable is replaced with the HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv, which contains information specific to each home unit. * The HomeUnitEnv contains: - A unit state, each home unit can have different package db flags - A set of dynflags, each home unit can have different flags - A HomePackageTable * LinkNode: A new node type is added to the ModuleGraph, this is used to place the linking step into the build plan so linking can proceed in parralel with other packages being built. * New invariant: Dependencies of a ModuleGraphNode can be completely determined by looking at the value of the node. In order to achieve this, downsweep now performs a more complete job of downsweeping and then the dependenices are recorded forever in the node rather than being computed again from the ModSummary. * Some transitive module calculations are rewritten to use the ModuleGraph which is more efficient. * There is always an active home unit, which simplifies modifying a lot of the existing API code which is unit agnostic (for example, in the driver). The road may be bumpy for a little while after this change but the basics are well-tested. One small metric increase, which we accept and also submodule update to haddock which removes ExtendedModSummary. Closes #10827 ------------------------- Metric Increase: MultiLayerModules ------------------------- Co-authored-by: Fendor <power.walross@gmail.com>
* Fix typosKrzysztof Gogolewski2021-12-2531-55/+55
|
* Properly filter for module visibility in resolvePackageImportMatthew Pickering2021-12-231-1/+1
| | | | | | | | | | | | This completes the fix for #20779 / !7123. Beforehand, the program worked by accident because the two versions of the library happened to be ordered properly (due to how the hashes were computed). In the real world I observed them being the other way around which meant the final lookup failed because we weren't filtering for visibility. I modified the test so that it failed (and it's fixed by this patch).
* Make callerCC profiling mode represent entry counter flag.Andreas Klebinger2021-12-231-2/+3
| | | | Fixes #20854
* Fix panic trying to -ddump-parsed-ast for implicit fixityAlan Zimmerman2021-12-221-7/+15
| | | | | | | | | | | | | | A declaration such as infixr ++++ is supplied with an implicit fixity of 9 in the parser, but uses an invalid SrcSpan to capture this. Use of this span triggers a panic. Fix the problem by not recording an exact print annotation for the non-existent fixity source. Closes #20846
* Cmm: DynFlags to CmmConfig refactordoyougnu2021-12-228-110/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | add files GHC.Cmm.Config, GHC.Driver.Config.Cmm Cmm: DynFlag references --> CmmConfig Cmm.Pipeline: reorder imports, add handshake Cmm: DynFlag references --> CmmConfig Cmm.Pipeline: DynFlag references --> CmmConfig Cmm.LayoutStack: DynFlag references -> CmmConfig Cmm.Info.Build: DynFlag references -> CmmConfig Cmm.Config: use profile to retrieve platform Cmm.CLabel: unpack NCGConfig in labelDynamic Cmm.Config: reduce CmmConfig surface area Cmm.Config: add cmmDoCmmSwitchPlans field Cmm.Config: correct cmmDoCmmSwitchPlans flag The original implementation dispatches work in cmmImplementSwitchPlans in an `otherwise` branch, hence we must add a not to correctly dispatch Cmm.Config: add cmmSplitProcPoints simplify Config remove cmmBackend, and cmmPosInd Cmm.CmmToAsm: move ncgLabelDynamic to CmmToAsm Cmm.CLabel: remove cmmLabelDynamic function Cmm.Config: rename cmmOptDoLinting -> cmmDoLinting testsuite: update CountDepsAst CountDepsParser
* Give plugins a better interface (#17957)Sylvain Henry2021-12-2113-74/+88
| | | | | | | | | | | | Plugins were directly fetched from HscEnv (hsc_static_plugins and hsc_plugins). The tight coupling of plugins and of HscEnv is undesirable and it's better to store them in a new Plugins datatype and to use it in the plugins' API (e.g. withPlugins, mapPlugins...). In the process, the interactive context (used by GHCi) got proper support for different static plugins than those used for loaded modules. Bump haddock submodule
* Introduce -dlint flagBen Gamari2021-12-211-0/+18
| | | | | | As suggested in #20601, this is a short-hand for enabling the usual GHC-internal sanity checks one typically leans on when debugging runtime crashes.
* Rename -fcatch-bottoms to -fcatch-nonexhaustive-casesBen Gamari2021-12-213-4/+4
| | | | As noted in #20601, the previous name was rather misleading.
* codeGen: Introduce flag to bounds-check array accessesBen Gamari2021-12-214-1/+123
| | | | | | | Here we introduce code generator support for instrument array primops with bounds checking, enabled with the `-fcheck-prim-bounds` flag. Introduced to debug #20769.
* Perf: avoid using (replicateM . length) when possibleSylvain Henry2021-12-174-8/+4
| | | | Extracted from !6622
* Demand: `Eq DmdType` modulo `defaultFvDmd` (#20827)Sebastian Graf2021-12-171-5/+35
| | | | | | Fixes #20827 by filtering out any default free variable demands (as per `defaultFvDmd`) prior to comparing the assocs of the `DmdEnv`. The details are in `Note [Demand type Equality]`.
* Binary: make withBinBuffer safeCheng Shao2021-12-171-5/+1
| | | | | | | With this patch, withBinBuffer will construct a ByteString that properly captures the reference to the BinHandle internal MutableByteArray#, making it safe to convert a BinHandle to ByteString and use that ByteString outside the continuation.
* Perf: inline exprIsCheapXSylvain Henry2021-12-171-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow specialization for the ok_app predicate. Perf improvements: Baseline Test Metric value New value Change ----------------------------------------------------------------------------- ManyAlternatives(normal) ghc/alloc 747317244.0 746444024.0 -0.1% ManyConstructors(normal) ghc/alloc 4005046448.0 4001548792.0 -0.1% MultiLayerModules(normal) ghc/alloc 3063361000.0 3063178472.0 -0.0% MultiLayerModulesRecomp(normal) ghc/alloc 894208428.0 894252496.0 +0.0% PmSeriesG(normal) ghc/alloc 48021692.0 47901592.0 -0.3% PmSeriesS(normal) ghc/alloc 61322504.0 61149008.0 -0.3% PmSeriesT(normal) ghc/alloc 90879364.0 90609048.0 -0.3% PmSeriesV(normal) ghc/alloc 60155376.0 59983632.0 -0.3% T10421(normal) ghc/alloc 112820720.0 112517208.0 -0.3% T10421a(normal) ghc/alloc 78783696.0 78557896.0 -0.3% T10547(normal) ghc/alloc 28331984.0 28354160.0 +0.1% T10858(normal) ghc/alloc 180715296.0 180226720.0 -0.3% T11195(normal) ghc/alloc 284139184.0 283981048.0 -0.1% T11276(normal) ghc/alloc 137830804.0 137688912.0 -0.1% T11303b(normal) ghc/alloc 44080856.0 43956152.0 -0.3% T11374(normal) ghc/alloc 249319644.0 249059288.0 -0.1% T11545(normal) ghc/alloc 971507488.0 971146136.0 -0.0% T11822(normal) ghc/alloc 131410208.0 131269664.0 -0.1% T12150(optasm) ghc/alloc 78866860.0 78762296.0 -0.1% T12227(normal) ghc/alloc 494467900.0 494138112.0 -0.1% T12234(optasm) ghc/alloc 56781044.0 56588256.0 -0.3% T12425(optasm) ghc/alloc 90462264.0 90240272.0 -0.2% T12545(normal) ghc/alloc 1694316588.0 1694128448.0 -0.0% T12707(normal) ghc/alloc 955665168.0 955005336.0 -0.1% T13035(normal) ghc/alloc 101875160.0 101713312.0 -0.2% T13056(optasm) ghc/alloc 366370168.0 365347632.0 -0.3% T13253(normal) ghc/alloc 333741472.0 332612920.0 -0.3% T13253-spj(normal) ghc/alloc 124947560.0 124427552.0 -0.4% T13379(normal) ghc/alloc 358997996.0 358879840.0 -0.0% T13701(normal) ghc/alloc 2400391456.0 2399956840.0 -0.0% T13719(normal) ghc/alloc 4193179228.0 4192476392.0 -0.0% T14052(ghci) ghc/alloc 2734741552.0 2735731808.0 +0.0% T14052Type(ghci) ghc/alloc 7323235724.0 7323042264.0 -0.0% T14683(normal) ghc/alloc 2990457260.0 2988899144.0 -0.1% T14697(normal) ghc/alloc 363606476.0 363452952.0 -0.0% T15164(normal) ghc/alloc 1291321780.0 1289491968.0 -0.1% T15304(normal) ghc/alloc 1277838020.0 1276208304.0 -0.1% T15630(normal) ghc/alloc 161074632.0 160388136.0 -0.4% T16190(normal) ghc/alloc 276567192.0 276235216.0 -0.1% T16577(normal) ghc/alloc 7564318656.0 7535598656.0 -0.4% T16875(normal) ghc/alloc 34867720.0 34752440.0 -0.3% T17096(normal) ghc/alloc 288477360.0 288156960.0 -0.1% T17516(normal) ghc/alloc 1712777224.0 1704655496.0 -0.5% T17836(normal) ghc/alloc 1092127336.0 1091709880.0 -0.0% T17836b(normal) ghc/alloc 52083516.0 51954056.0 -0.2% T17977(normal) ghc/alloc 44552228.0 44425448.0 -0.3% T17977b(normal) ghc/alloc 40540252.0 40416856.0 -0.3% T18140(normal) ghc/alloc 81908200.0 81678928.0 -0.3% T18223(normal) ghc/alloc 1166459176.0 1164418104.0 -0.2% T18282(normal) ghc/alloc 131123648.0 130740432.0 -0.3% T18304(normal) ghc/alloc 86486796.0 86223088.0 -0.3% T18478(normal) ghc/alloc 746029440.0 745619968.0 -0.1% T18698a(normal) ghc/alloc 337037580.0 336533824.0 -0.1% T18698b(normal) ghc/alloc 398324600.0 397696400.0 -0.2% T18923(normal) ghc/alloc 68496432.0 68286264.0 -0.3% T1969(normal) ghc/alloc 760424696.0 759641664.0 -0.1% T19695(normal) ghc/alloc 1421672472.0 1413682104.0 -0.6% T20049(normal) ghc/alloc 88601524.0 88336560.0 -0.3% T3064(normal) ghc/alloc 190808832.0 190659328.0 -0.1% T3294(normal) ghc/alloc 1604483120.0 1604339080.0 -0.0% T4801(normal) ghc/alloc 296501624.0 296388448.0 -0.0% T5030(normal) ghc/alloc 364336308.0 364206240.0 -0.0% T5321FD(normal) ghc/alloc 270688492.0 270386832.0 -0.1% T5321Fun(normal) ghc/alloc 300860396.0 300559200.0 -0.1% T5631(normal) ghc/alloc 575822760.0 575579160.0 -0.0% T5642(normal) ghc/alloc 470243356.0 468988784.0 -0.3% T5837(normal) ghc/alloc 35936468.0 35821360.0 -0.3% T6048(optasm) ghc/alloc 102587024.0 102222000.0 -0.4% T783(normal) ghc/alloc 386539204.0 386003344.0 -0.1% T9020(optasm) ghc/alloc 247435312.0 247324184.0 -0.0% T9198(normal) ghc/alloc 47170036.0 47054840.0 -0.2% T9233(normal) ghc/alloc 677186820.0 676550032.0 -0.1% T9630(normal) ghc/alloc 1456411516.0 1451045736.0 -0.4% T9675(optasm) ghc/alloc 427190224.0 426812568.0 -0.1% T9872a(normal) ghc/alloc 1704660040.0 1704681856.0 +0.0% T9872b(normal) ghc/alloc 2180109488.0 2180130856.0 +0.0% T9872c(normal) ghc/alloc 1760209640.0 1760231456.0 +0.0% T9872d(normal) ghc/alloc 501126052.0 500973488.0 -0.0% T9961(normal) ghc/alloc 353244688.0 353063104.0 -0.1% TcPlugin_RewritePerf(normal) ghc/alloc 2387276808.0 2387254168.0 -0.0% WWRec(normal) ghc/alloc 588651140.0 587684704.0 -0.2% hard_hole_fits(normal) ghc/alloc 492063812.0 491798360.0 -0.1% hie002(normal) ghc/alloc 9334355960.0 9334396872.0 +0.0% parsing001(normal) ghc/alloc 537410584.0 537421736.0 +0.0% geo. mean -0.2%
* Change isUnliftedTyCon to marshalablePrimTyCon (#20401)Krzysztof Gogolewski2021-12-178-203/+42
| | | | | | | | | | | | | | | | | | | | | | | | isUnliftedTyCon was used in three places: Ticky, Template Haskell and FFI checks. It was straightforward to remove it from Ticky and Template Haskell. It is now used in FFI only and renamed to marshalablePrimTyCon. Previously, it was fetching information from a field in PrimTyCon called is_unlifted. Instead, I've changed the code to compute liftedness based on the kind. isFFITy and legalFFITyCon are removed. They were only referred from an old comment that I removed. There were three functions to define a PrimTyCon, but the only difference was that they were setting is_unlifted to True or False. Everything is now done in mkPrimTyCon. I also added missing integer types in Ticky.hs, I think it was an oversight. Fixes #20401
* Plugin load order should follow the commandline order (fixes #17884)Andrei Barbu2021-12-152-2/+4
| | | | | | | In the past the order was reversed because flags are consed onto a list. No particular behavior was documented. We now reverse the flags and document the behavior.
* CmmToLlvm: rename LCGConfig -> LlvmCgConfigdoyougnu2021-12-149-107/+107
| | | | | | | | | | | | | | | | | | | | CmmToLlvm: renamce lcgPlatform -> llvmCgPlatform CmmToLlvm: rename lcgContext -> llvmCgContext CmmToLlvm: rename lcgFillUndefWithGarbage CmmToLlvm: rename lcgSplitSections CmmToLlvm: lcgBmiVersion -> llvmCgBmiVersion CmmToLlvm: lcgLlvmVersion -> llvmCgLlvmVersion CmmToLlvm: lcgDoWarn -> llvmCgDoWarn CmmToLlvm: lcgLlvmConfig -> llvmCgLlvmConfig CmmToLlvm: llvmCgPlatformMisc --> llvmCgLlvmTarget
* CmmToLlvm.Config: strictify LlvmConfig fielddoyougnu2021-12-141-2/+3
|
* LLVM.CodeGen: use fast-string literalsdoyougnu2021-12-141-34/+145
| | | | | | | That is remove factorization of common strings and string building code for the LLVM code gen ops. Replace these with string literals to obey the FastString rewrite rule in GHC.Data.FastString and compute the string length at compile time
* SysTools.Tasks Llvm.Types: remove redundant importdoyougnu2021-12-142-3/+2
| | | | | | | | Llvm.Types: remove redundant import SysTools.Tasks: remove redundant import - namely CmmToLlvm.Base
* CmmToLlvm: Remove DynFlags, add LlvmCgConfigdoyougnu2021-12-1412-226/+249
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CodeOutput: LCGConfig, add handshake initLCGConfig Add two modules: GHC.CmmToLlvm.Config -- to hold the Llvm code gen config GHC.Driver.Config.CmmToLlvm -- for initialization, other utils CmmToLlvm: remove HasDynFlags, add LlvmConfig CmmToLlvm: add lcgContext to LCGConfig CmmToLlvm.Base: DynFlags --> LCGConfig Llvm: absorb LlvmOpts into LCGConfig CmmToLlvm.Ppr: swap DynFlags --> LCGConfig CmmToLlvm.CodeGen: swap DynFlags --> LCGConfig CmmToLlvm.CodeGen: swap DynFlags --> LCGConfig CmmToLlvm.Data: swap LlvmOpts --> LCGConfig CmmToLlvm: swap DynFlags --> LCGConfig CmmToLlvm: move LlvmVersion to CmmToLlvm.Config Additionally: - refactor Config and initConfig to hold LlvmVersion - push IO needed to get LlvmVersion to boundary between Cmm and LLvm code generation - remove redundant imports, this is much cleaner! CmmToLlvm.Config: store platformMisc_llvmTarget instead of all of platformMisc
* ghc-bin: Add --merge-objs modeBen Gamari2021-12-144-27/+38
| | | | | | | | | | This adds a new mode, `--merge-objs`, which can be used to produce merged GHCi library objects. As future work we will rip out the object-merging logic in Hadrian and Cabal and instead use this mode. Closes #20712.
* compiler: Use withFile instead of bracketBen Gamari2021-12-141-2/+1
| | | | A minor refactoring noticed by hlint.
* compiler: Drop `Maybe ModLocation` from T_MergeForeignBen Gamari2021-12-143-8/+8
| | | | This field was entirely unused.
* Ghci environment: Do not remove shadowed idsJoachim Breitner2021-12-142-43/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Names defined earier but shadowed need to be kept around, e.g. for type signatures: ``` ghci> data T = T ghci> let t = T ghci> data T = T ghci> :t t t :: Ghci1.T ``` and indeed they can be used: ``` ghci> let t2 = Ghci1.T :: Ghci1.T ghci> :t t2 t2 :: Ghci1.T ``` However, previously this did not happen for ids (non-types), although they are still around under the qualified name internally: ``` ghci> let t = "other t" ghci> t' <interactive>:8:1: error: • Variable not in scope: t' • Perhaps you meant one of these: ‘Ghci2.t’ (imported from Ghci2), ‘t’ (line 7), ‘t2’ (line 5) ghci> Ghci2.t <interactive>:9:1: error: • GHC internal error: ‘Ghci2.t’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the expression: Ghci2.t In an equation for ‘it’: it = Ghci2.t ``` This fixes the problem by simply removing the code that tries to remove shadowed ids from the environment. Now you can refer to shadowed ids using `Ghci2.t`, just like you can do for data and type constructors. This simplifies the code, makes terms and types more similar, and also fixes #20455. Now all names ever defined in GHCi are in `ic_tythings`, which is printed by `:show bindings`. But for that commands, it seems to be more ergonomic to only list those bindings that are not shadowed. Or, even if it is not more ergonomic, it’s the current behavour. So let's restore that by filtering in `icInScopeTTs`. Of course a single `TyThing` can be associated with many names. We keep it it in the bindings if _any_ of its names are still visible unqualifiedly. It's a judgement call. This commit also turns a rather old comment into a test files. The comment is is rather stale and things are better explained elsewhere. Fixes #925. Two test cases are regressing: T14052(ghci) ghc/alloc 2749444288.0 12192109912.0 +343.4% BAD T14052Type(ghci) ghc/alloc 7365784616.0 10767078344.0 +46.2% BAD This is not unexpected; the `ic_tythings list grows` a lot more if we don’t remove shadowed Ids. I tried to alleviate it a bit with earlier MRs, but couldn’t make up for it completely. Metric Increase: T14052 T14052Type
* GHC.Utils.Misc.only: Add doc string.Andreas Klebinger2021-12-141-0/+4
| | | | | | | This function expects a singleton list as argument but only checks this in debug builds. I've added a docstring saying so. Fixes #20797
* Add PromotedInfixT/PromotedUInfixT to THJakob Brünker2021-12-112-40/+65
| | | | | | | | | | | | Previously, it was not possible to refer to a data constructor using InfixT with a dynamically bound name (i.e. a name with NameFlavour `NameS` or `NameQ`) if a type constructor of the same name exists. This commit adds promoted counterparts to InfixT and UInfixT, analogously to how PromotedT is the promoted counterpart to ConT. Closes #20773
* Use file hash cache when hashing object file dependenciesMatthew Pickering2021-12-091-1/+2
| | | | | | | | | | | | | | | | | | | This fixes the immediate problem that we hash the same file multiple different times which causes quite a noticeably performance regression. In the future we can probably do better than this by storing the implementation hash in the interface file rather than dependending on hashing the object file. Related to #20604 which notes some inefficiencies with the current recompilation logic. Closes #20790 ------------------------- Metric Decrease: T14052Type -------------------------
* Remove `optLevel` from `DynFlags` (closes #20500)Gergo ERDI2021-12-091-17/+28
|
* Add `Opt_CoreConstantFolding` to turn on constant folding (#20500)Gergo ERDI2021-12-094-3/+8
| | | | | Previously, `-O1` and `-O2`, by way of their effect on the compilation pipeline, they implicitly turned on constant folding
* Use same optimization pipeline regardless of `optLevel` (#20500)Gergo ERDI2021-12-091-13/+9
|
* package imports: Take into account package visibility when renamingMatthew Pickering2021-12-096-13/+30
| | | | | | | | | | | | In 806e49ae the package imports refactoring code was modified to rename package imports. There was a small oversight which meant the code didn't account for module visibility. This patch fixes that oversight. In general the "lookupPackageName" function is unsafe to use as it doesn't account for package visiblity/thinning/renaming etc, there is just one use in the compiler which would be good to audit. Fixes #20779
* Perf: remove an indirection when fetching the unique maskSylvain Henry2021-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Slight decrease but still noticeable on CI: Baseline Test Metric value New value Change ----------------------------------------------------------------------------- ManyAlternatives(normal) ghc/alloc 747607676.0 747458936.0 -0.0% ManyConstructors(normal) ghc/alloc 4003722296.0 4003530032.0 -0.0% MultiLayerModules(normal) ghc/alloc 3064539560.0 3063984552.0 -0.0% MultiLayerModulesRecomp(normal) ghc/alloc 894700016.0 894700624.0 +0.0% PmSeriesG(normal) ghc/alloc 48410952.0 48262496.0 -0.3% PmSeriesS(normal) ghc/alloc 61561848.0 61415768.0 -0.2% PmSeriesT(normal) ghc/alloc 90975784.0 90829360.0 -0.2% PmSeriesV(normal) ghc/alloc 60405424.0 60259008.0 -0.2% T10421(normal) ghc/alloc 113275928.0 113137168.0 -0.1% T10421a(normal) ghc/alloc 79195676.0 79050112.0 -0.2% T10547(normal) ghc/alloc 28720176.0 28710008.0 -0.0% T10858(normal) ghc/alloc 180992412.0 180857400.0 -0.1% T11195(normal) ghc/alloc 283452220.0 283293832.0 -0.1% T11276(normal) ghc/alloc 137882128.0 137745840.0 -0.1% T11303b(normal) ghc/alloc 44453956.0 44309184.0 -0.3% T11374(normal) ghc/alloc 248118668.0 247979880.0 -0.1% T11545(normal) ghc/alloc 971994728.0 971852696.0 -0.0% T11822(normal) ghc/alloc 131544864.0 131399024.0 -0.1% T12150(optasm) ghc/alloc 79336468.0 79191888.0 -0.2% T12227(normal) ghc/alloc 495064180.0 494943040.0 -0.0% T12234(optasm) ghc/alloc 57198468.0 57053568.0 -0.3% T12425(optasm) ghc/alloc 90928696.0 90793440.0 -0.1% T12545(normal) ghc/alloc 1695417772.0 1695275744.0 -0.0% T12707(normal) ghc/alloc 956258984.0 956138864.0 -0.0% T13035(normal) ghc/alloc 102279484.0 102132616.0 -0.1% T13056(optasm) ghc/alloc 367196556.0 367066408.0 -0.0% T13253(normal) ghc/alloc 334365844.0 334255264.0 -0.0% T13253-spj(normal) ghc/alloc 125474884.0 125328672.0 -0.1% T13379(normal) ghc/alloc 359185604.0 359036960.0 -0.0% T13701(normal) ghc/alloc 2403026480.0 2402677464.0 -0.0% T13719(normal) ghc/alloc 4192234752.0 4192039448.0 -0.0% T14052(ghci) ghc/alloc 2745868552.0 2747706176.0 +0.1% T14052Type(ghci) ghc/alloc 7335937964.0 7336283280.0 +0.0% T14683(normal) ghc/alloc 2992557736.0 2992436872.0 -0.0% T14697(normal) ghc/alloc 363391248.0 363222920.0 -0.0% T15164(normal) ghc/alloc 1292578008.0 1292434240.0 -0.0% T15304(normal) ghc/alloc 1279603472.0 1279465944.0 -0.0% T15630(normal) ghc/alloc 161707776.0 161602632.0 -0.1% T16190(normal) ghc/alloc 276904644.0 276555264.0 -0.1% T16577(normal) ghc/alloc 7573033016.0 7572982752.0 -0.0% T16875(normal) ghc/alloc 34937980.0 34796592.0 -0.4% T17096(normal) ghc/alloc 287436348.0 287299368.0 -0.0% T17516(normal) ghc/alloc 1714727484.0 1714617664.0 -0.0% T17836(normal) ghc/alloc 1091095748.0 1090958168.0 -0.0% T17836b(normal) ghc/alloc 52467912.0 52321296.0 -0.3% T17977(normal) ghc/alloc 44971660.0 44826480.0 -0.3% T17977b(normal) ghc/alloc 40941128.0 40793160.0 -0.4% T18140(normal) ghc/alloc 82363124.0 82213056.0 -0.2% T18223(normal) ghc/alloc 1168448128.0 1168333624.0 -0.0% T18282(normal) ghc/alloc 131577844.0 131440400.0 -0.1% T18304(normal) ghc/alloc 86988664.0 86844432.0 -0.2% T18478(normal) ghc/alloc 742992400.0 742871136.0 -0.0% T18698a(normal) ghc/alloc 337654412.0 337526792.0 -0.0% T18698b(normal) ghc/alloc 398840772.0 398716472.0 -0.0% T18923(normal) ghc/alloc 68964992.0 68818768.0 -0.2% T1969(normal) ghc/alloc 764285884.0 764156168.0 -0.0% T19695(normal) ghc/alloc 1395577984.0 1395552552.0 -0.0% T20049(normal) ghc/alloc 89159032.0 89012952.0 -0.2% T3064(normal) ghc/alloc 191194856.0 191051816.0 -0.1% T3294(normal) ghc/alloc 1604762016.0 1604656488.0 -0.0% T4801(normal) ghc/alloc 296829368.0 296687824.0 -0.0% T5030(normal) ghc/alloc 364720540.0 364580152.0 -0.0% T5321FD(normal) ghc/alloc 271090004.0 270950824.0 -0.1% T5321Fun(normal) ghc/alloc 301244320.0 301102960.0 -0.0% T5631(normal) ghc/alloc 576154548.0 576022904.0 -0.0% T5642(normal) ghc/alloc 471105876.0 470967552.0 -0.0% T5837(normal) ghc/alloc 36328620.0 36186720.0 -0.4% T6048(optasm) ghc/alloc 103125988.0 102981024.0 -0.1% T783(normal) ghc/alloc 386945556.0 386795984.0 -0.0% T9020(optasm) ghc/alloc 247835012.0 247696704.0 -0.1% T9198(normal) ghc/alloc 47556208.0 47413784.0 -0.3% T9233(normal) ghc/alloc 682210596.0 682069960.0 -0.0% T9630(normal) ghc/alloc 1429689648.0 1429581168.0 -0.0% T9675(optasm) ghc/alloc 431092812.0 430943192.0 -0.0% T9872a(normal) ghc/alloc 1705052592.0 1705042064.0 -0.0% T9872b(normal) ghc/alloc 2180406760.0 2180395784.0 -0.0% T9872c(normal) ghc/alloc 1760508464.0 1760497936.0 -0.0% T9872d(normal) ghc/alloc 501517968.0 501309464.0 -0.0% T9961(normal) ghc/alloc 354037204.0 353891576.0 -0.0% TcPlugin_RewritePerf(normal) ghc/alloc 2381708520.0 2381550824.0 -0.0% WWRec(normal) ghc/alloc 589553520.0 589407216.0 -0.0% hard_hole_fits(normal) ghc/alloc 492122188.0 492470648.0 +0.1% hie002(normal) ghc/alloc 9336434800.0 9336443496.0 +0.0% parsing001(normal) ghc/alloc 537680944.0 537659824.0 -0.0% geo. mean -0.1%
* generalize GHC.Cmm.Dataflow to work over any node typeNorman Ramsey2021-12-071-31/+46
| | | | | | See #20725. The commit includes source-code changes and a test case.
* More permissive parsing of higher-rank type IPssheaf2021-12-071-1/+1
| | | | | | | | | | | | | | | | | The parser now accepts implicit parameters with higher-rank types, such as `foo :: (?ip :: forall a. a -> a) => ...` Before this patch, we instead insisted on parentheses like so: `foo :: (?ip :: (forall a. a -> a)) => ...` The rest of the logic surrounding implicit parameters is unchanged; in particular, even with ImpredicativeTypes, this idiom is not likely to be very useful. Fixes #20654
* compiler: Eliminate accidental loop in GHC.SysTools.BaseDirBen Gamari2021-12-071-2/+2
| | | | | | | | As noted in #20757, `GHC.SysTools.BaseDir.findToolDir` previously contained an loop, which would be triggered in the case that the search failed. Closes #20757.
* Revert "Data.List specialization to []"Matthew Pickering2021-12-031-4/+1
| | | | | | | | | | This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2. This implements the first step in the plan formulated in #20025 to improve the communication and migration strategy for the proposed changes to Data.List. Requires changing the haddock submodule to update the test output.
* Require all dirty_MUT_VAR callers to do explicit stg_MUT_VAR_CLEAN_info ↵nineonine2021-12-022-5/+15
| | | | comparison (#20088)
* CmmToC: Cast possibly-signed results as unsignedBen Gamari2021-12-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.
* CmmToC: Always cast arguments as unsignedBen Gamari2021-12-021-4/+28
| | | | | | | 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.
* CmmToC: Zero-extend sub-word size resultsBen Gamari2021-12-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.
* CmmToC: Fix width of shift operationsBen Gamari2021-12-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.
* nativeGen/aarch64: Fix handling of subword valuesBen Gamari2021-12-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.
* cmm/opt: Fold away shifts larger than shiftee widthBen Gamari2021-12-021-2/+12
| | | | | This is necessary for lint-correctness since we no longer allow such shifts in Cmm.
View Lorry Controller Status