Commits on Source (41)
-
T16190 is meant to test a NCG feature. It has already caused spurious failures in other MRs (e.g. !2165) when LLVM is used.
4fd0f17d -
* Remove several uses of `sdocWithDynFlags`, especially in GHC.Llvm.* * Add LlvmOpts datatype to store Llvm backend options * Remove Outputable instances (for LlvmVar, LlvmLit, LlvmStatic and Llvm.MetaExpr) which require LlvmOpts. * Rename ppMetaExpr into ppMetaAnnotExpr (pprMetaExpr is now used in place of `ppr :: MetaExpr -> SDoc`)
4e6dcc7b -
1165b395
-
* rename thisPackage into homeUnit * document and refactor several Backpack things
0447c173 -
2c82f343
-
Instead of always querying DynFlags to know whether we are allowed to use virtual units (i.e. instantiated on-the-fly, cf Note [About units] in GHC.Unit), we store it once for all in `PackageState.allowVirtualUnits`. This avoids using DynFlags too much (cf #17957) and is preliminary work for #14335.
4d93c287 -
* use UnitId instead of String to identify wired-in units * use UnitId instead of Unit in the backend (Unit are only use by Backpack to produce type-checked interfaces, not real code) * rename lookup functions for consistency * documentation
09a76e92 -
ec4c52cd
-
* Remove WiredInUnitId and WiredUnitId type aliases
18449b32 -
98b5e494
-
c4f90e16
-
There is no Map involved
6ad18f85 -
The terminology changed over time and now package databases contain "units" (there can be several units compiled from a single Cabal package: one per-component, one for each option set, one per instantiation, etc.). We should try to be consistent internally and use "units": that's what this renaming does. Maybe one day we'll fix the UI too (e.g. replace -package-id with -unit-id, we already have -this-unit-id and ghc-pkg has -unit-id...) but it's not done in this patch. * rename getPkgFrameworkOpts into getUnitFrameworkOpts * rename UnitInfoMap into ClosureUnitInfoMap * rename InstalledPackageIndex into UnitInfoMap * rename UnusablePackages into UnusableUnits * rename PackagePrecedenceIndex into UnitPrecedenceMap * rename PackageDatabase into UnitDatabase * rename pkgDatabase into unitDatabases * rename pkgState into unitState * rename initPackages into initUnits * rename renamePackage into renameUnitInfo * rename UnusablePackageReason into UnusableUnitReason * rename getPackage* into getUnit* * etc.
a347d747 -
2ff6816c
-
fd07e3c8
-
* rename PackageState into UnitState * rename findWiredInPackages into findWiredInUnits * rename lookupModuleInAll[Packages,Units] * etc.
136f74f4 -
1981a957
-
abebfe36
-
145cf0cb
-
* Remove preload parameter (unused) * Don't explicitly return preloaded units: redundant because already returned as "preloadUnits" field of UnitState
ee7e44d9 -
a3171103
-
f45c4877
-
bdc777c6
-
77089dd6
-
73ea5f2c
-
f2be023d
-
7a29830d
-
e87f4557
-
9e8c5b51
-
Avoid directly querying flags from DynFlags to build the UnitState. Instead go via UnitConfig so that we could reuse this to make another UnitState for plugins.
f1a97232 -
282a1621
-
6d5a9f78
-
a59f1583
-
Preload units can be retrieved in UnitState when needed (i.e. in GHCi)
6ebfa1e1 -
80a09bd7
-
2bd99a76
-
Metric Decrease: T12150 T12234 T5837 Metric Increase: T16190
52286510 -
Ticket #18304 showed that we need to be very careful when exploring the demand (esp usage demand) on recursive product types. This patch solves the problem by trimming the demand on such types -- in effect, a form of "widening". See the Note [Trimming a demand to a type] in DmdAnal, which explains how I did this by piggy-backing on an existing mechansim for trimming demands becuase of GADTs. The significant payload of this patch is very small indeed: * Make GHC.Core.Opt.WorkWrap.Utils.typeShape use RecTcChecker to avoid looking through recursive types. But on the way * I found that ae_rec_tc was entirely inoperative and did nothing. So I removed it altogether from DmdAnal. * I moved some code around in DmdAnal and Demand. (There are no actual changes in dmdFix.) * I changed the API of DmsAnal.dmdAnalRhsLetDown to return a StrictSig rather than a decorated Id * I removed the dead function peelTsFuns from Demand Performance effects: Nofib: 0.0% changes. Not surprising, because they don't use recursive products Perf tests T12227: 1% increase in compiler allocation, becuase $cto gets w/w'd. It did not w/w before because it takes a deeply nested argument, so the worker gets too many args, so we abandon w/w altogether (see GHC.Core.Opt.WorkWrap.Utils.isWorkerSmallEnough) With this patch we trim the demands. That is not strictly necessary (since these Generic type constructors are like tuples -- they can't cause a loop) but the net result is that we now w/w $cto which is fine. UniqLoop: 16% decrease in /runtime/ allocation. The UniqSupply is a recursive product, so currently we abandon all strictness on 'churn'. With this patch 'churn' gets useful strictness, and we w/w it. Hooray Metric Decrease: UniqLoop Metric Increase: T12227
e2e8210a -
ae1d6926
-
As noted in #18319, this test was previously very fragile. Increase its size to make it more likely that its fails with its newly-increased acceptance threshold. Metric Increase: T12150
4917463e
Showing
- compiler/GHC.hs 19 additions, 15 deletionscompiler/GHC.hs
- compiler/GHC/Builtin/Names.hs 10 additions, 10 deletionscompiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Names/TH.hs 1 addition, 1 deletioncompiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/ByteCode/Linker.hs 1 addition, 1 deletioncompiler/GHC/ByteCode/Linker.hs
- compiler/GHC/Cmm/CLabel.hs 19 additions, 18 deletionscompiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Parser.y 12 additions, 12 deletionscompiler/GHC/Cmm/Parser.y
- compiler/GHC/CmmToAsm/Config.hs 0 additions, 2 deletionscompiler/GHC/CmmToAsm/Config.hs
- compiler/GHC/CmmToAsm/Monad.hs 0 additions, 1 deletioncompiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToLlvm.hs 9 additions, 5 deletionscompiler/GHC/CmmToLlvm.hs
- compiler/GHC/CmmToLlvm/Base.hs 19 additions, 21 deletionscompiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs 9 additions, 6 deletionscompiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/CmmToLlvm/Data.hs 4 additions, 5 deletionscompiler/GHC/CmmToLlvm/Data.hs
- compiler/GHC/CmmToLlvm/Ppr.hs 10 additions, 8 deletionscompiler/GHC/CmmToLlvm/Ppr.hs
- compiler/GHC/Core/Opt/DmdAnal.hs 168 additions, 120 deletionscompiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs 31 additions, 18 deletionscompiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs 5 additions, 5 deletionscompiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Backpack.hs 28 additions, 25 deletionscompiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/CodeOutput.hs 2 additions, 2 deletionscompiler/GHC/Driver/CodeOutput.hs
- compiler/GHC/Driver/Finder.hs 23 additions, 19 deletionscompiler/GHC/Driver/Finder.hs
- compiler/GHC/Driver/Main.hs 14 additions, 17 deletionscompiler/GHC/Driver/Main.hs