| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discovered in #22272, dehydration of the unfolding info of a
recursive definition used to involve a traversal of the definition
itself, which in turn involves traversing the unfolding info. Hence,
a loop.
Instead, we now store enough data in the interface that we can produce
the unfolding info without this traversal. See Note [Tying the 'CoreUnfolding' knot]
for details.
Fixes #22272
Co-authored-by: Simon Peyton Jones <simon.peytonjones@gmail.com>
|
|
|
|
|
|
|
| |
Since Constraint became a synonym for CONSTRAINT 'LiftedRep,
we need the same code for handling printing as for the synonym
Type = TYPE 'LiftedRep.
This addresses the same bug as #18594, so I'm reusing the test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This big patch addresses the rats-nest of issues that have plagued
us for years, about the relationship between Type and Constraint.
See #11715/#21623.
The main payload of the patch is:
* To introduce CONSTRAINT :: RuntimeRep -> Type
* To make TYPE and CONSTRAINT distinct throughout the compiler
Two overview Notes in GHC.Builtin.Types.Prim
* Note [TYPE and CONSTRAINT]
* Note [Type and Constraint are not apart]
This is the main complication.
The specifics
* New primitive types (GHC.Builtin.Types.Prim)
- CONSTRAINT
- ctArrowTyCon (=>)
- tcArrowTyCon (-=>)
- ccArrowTyCon (==>)
- funTyCon FUN -- Not new
See Note [Function type constructors and FunTy]
and Note [TYPE and CONSTRAINT]
* GHC.Builtin.Types:
- New type Constraint = CONSTRAINT LiftedRep
- I also stopped nonEmptyTyCon being built-in; it only needs to be wired-in
* Exploit the fact that Type and Constraint are distinct throughout GHC
- Get rid of tcView in favour of coreView.
- Many tcXX functions become XX functions.
e.g. tcGetCastedTyVar --> getCastedTyVar
* Kill off Note [ForAllTy and typechecker equality], in (old)
GHC.Tc.Solver.Canonical. It said that typechecker-equality should ignore
the specified/inferred distinction when comparein two ForAllTys. But
that wsa only weakly supported and (worse) implies that we need a separate
typechecker equality, different from core equality. No no no.
* GHC.Core.TyCon: kill off FunTyCon in data TyCon. There was no need for it,
and anyway now we have four of them!
* GHC.Core.TyCo.Rep: add two FunTyFlags to FunCo
See Note [FunCo] in that module.
* GHC.Core.Type. Lots and lots of changes driven by adding CONSTRAINT.
The key new function is sORTKind_maybe; most other changes are built
on top of that.
See also `funTyConAppTy_maybe` and `tyConAppFun_maybe`.
* Fix a longstanding bug in GHC.Core.Type.typeKind, and Core Lint, in
kinding ForAllTys. See new tules (FORALL1) and (FORALL2) in GHC.Core.Type.
(The bug was that before (forall (cv::t1 ~# t2). blah), where
blah::TYPE IntRep, would get kind (TYPE IntRep), but it should be
(TYPE LiftedRep). See Note [Kinding rules for types] in GHC.Core.Type.
* GHC.Core.TyCo.Compare is a new module in which we do eqType and cmpType.
Of course, no tcEqType any more.
* GHC.Core.TyCo.FVs. I moved some free-var-like function into this module:
tyConsOfType, visVarsOfType, and occCheckExpand. Refactoring only.
* GHC.Builtin.Types. Compiletely re-engineer boxingDataCon_maybe to
have one for each /RuntimeRep/, rather than one for each /Type/.
This dramatically widens the range of types we can auto-box.
See Note [Boxing constructors] in GHC.Builtin.Types
The boxing types themselves are declared in library ghc-prim:GHC.Types.
GHC.Core.Make. Re-engineer the treatment of "big" tuples (mkBigCoreVarTup
etc) GHC.Core.Make, so that it auto-boxes unboxed values and (crucially)
types of kind Constraint. That allows the desugaring for arrows to work;
it gathers up free variables (including dictionaries) into tuples.
See Note [Big tuples] in GHC.Core.Make.
There is still work to do here: #22336. But things are better than
before.
* GHC.Core.Make. We need two absent-error Ids, aBSENT_ERROR_ID for types of
kind Type, and aBSENT_CONSTRAINT_ERROR_ID for vaues of kind Constraint.
Ditto noInlineId vs noInlieConstraintId in GHC.Types.Id.Make;
see Note [inlineId magic].
* GHC.Core.TyCo.Rep. Completely refactor the NthCo coercion. It is now called
SelCo, and its fields are much more descriptive than the single Int we used to
have. A great improvement. See Note [SelCo] in GHC.Core.TyCo.Rep.
* GHC.Core.RoughMap.roughMatchTyConName. Collapse TYPE and CONSTRAINT to
a single TyCon, so that the rough-map does not distinguish them.
* GHC.Core.DataCon
- Mainly just improve documentation
* Some significant renamings:
GHC.Core.Multiplicity: Many --> ManyTy (easier to grep for)
One --> OneTy
GHC.Core.TyCo.Rep TyCoBinder --> GHC.Core.Var.PiTyBinder
GHC.Core.Var TyCoVarBinder --> ForAllTyBinder
AnonArgFlag --> FunTyFlag
ArgFlag --> ForAllTyFlag
GHC.Core.TyCon TyConTyCoBinder --> TyConPiTyBinder
Many functions are renamed in consequence
e.g. isinvisibleArgFlag becomes isInvisibleForAllTyFlag, etc
* I refactored FunTyFlag (was AnonArgFlag) into a simple, flat data type
data FunTyFlag
= FTF_T_T -- (->) Type -> Type
| FTF_T_C -- (-=>) Type -> Constraint
| FTF_C_T -- (=>) Constraint -> Type
| FTF_C_C -- (==>) Constraint -> Constraint
* GHC.Tc.Errors.Ppr. Some significant refactoring in the TypeEqMisMatch case
of pprMismatchMsg.
* I made the tyConUnique field of TyCon strict, because I
saw code with lots of silly eval's. That revealed that
GHC.Settings.Constants.mAX_SUM_SIZE can only be 63, because
we pack the sum tag into a 6-bit field. (Lurking bug squashed.)
Fixes
* #21530
Updates haddock submodule slightly.
Performance changes
~~~~~~~~~~~~~~~~~~~
I was worried that compile times would get worse, but after
some careful profiling we are down to a geometric mean 0.1%
increase in allocation (in perf/compiler). That seems fine.
There is a big runtime improvement in T10359
Metric Decrease:
LargeRecord
MultiLayerModulesTH_OneShot
T13386
T13719
Metric Increase:
T8095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two bugs here:
1. Treating type-level constructors as PromotedDataCon doesn't always
work, in particular because constructors promoted via DataKinds are
called both T and 'T. (Tests T22332a, T22332b, T22315a, T22315b)
Fix: guard these cases with isDataKindsPromotedDataCon.
2. Type-level constructors were sent to the code generator, producing
things like constructor wrappers. (Tests T22332a, T22332b)
Fix: test for them in isDataTyCon.
Other changes:
* changed the marking of "type data" DataCon's as suggested by SPJ.
* added a test TDGADT for a type-level GADT.
* comment tweaks
* change tcIfaceTyCon to ignore IfaceTyConInfo, so that IfaceTyConInfo
is used only for pretty printing, not for typechecking. (SPJ)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds three new flags
* -fwrite-if-simplified-core: Writes the whole core program into an interface
file
* -fbyte-code-and-object-code: Generate both byte code and object code
when compiling a file
* -fprefer-byte-code: Prefer to use byte-code if it's available when
running TH splices.
The goal for including the core bindings in an interface file is to be able to restart the compiler pipeline
at the point just after simplification and before code generation. Once compilation is
restarted then code can be created for the byte code backend.
This can significantly speed up
start-times for projects in GHCi. HLS already implements its own version of these extended interface
files for this reason.
Preferring to use byte-code means that we can avoid some potentially
expensive code generation steps (see #21700)
* Producing object code is much slower than producing bytecode, and normally you
need to compile with `-dynamic-too` to produce code in the static and dynamic way, the
dynamic way just for Template Haskell execution when using a dynamically linked compiler.
* Linking many large object files, which happens once per splice, can be quite
expensive compared to linking bytecode.
And you can get GHC to compile the necessary byte code so
`-fprefer-byte-code` has access to it by using
`-fbyte-code-and-object-code`.
Fixes #21067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I finally got tired of the way that IfaceUnfolding reflected
a previous structure of unfoldings, not the current one. This
MR refactors UnfoldingSource and IfaceUnfolding to be simpler
and more consistent.
It's largely just a refactor, but in UnfoldingSource (which moves
to GHC.Types.Basic, since it is now used in IfaceSyn too), I
distinguish between /user-specified/ and /system-generated/ stable
unfoldings.
data UnfoldingSource
= VanillaSrc
| StableUserSrc -- From a user-specified pragma
| StableSystemSrc -- From a system-generated unfolding
| CompulsorySrc
This has a minor effect in CSE (see the use of isisStableUserUnfolding
in GHC.Core.Opt.CSE), which I tripped over when working on
specialisation, but it seems like a Good Thing to know anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the code
{-# LANGUAGE OverloadedRecordUpdate #-}
operatorUpdate f = f{(+) = 1}
There are no exact print annotations for the parens around the +
symbol, nor does normal ppr print them.
This MR fixes that.
Closes #21805
Updates haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to put OtherCon unfoldings on lambda binders of workers
and sometimes also join points/specializations with with the
assumption that since the wrapper would force these arguments
once we execute the RHS they would indeed be in WHNF.
This was wrong for reasons detailed in #21472. So now we purge
evaluated unfoldings from *all* lambda binders.
This fixes #21472, but at the cost of sometimes not using as efficient a
calling convention. It can also change inlining behaviour as some
occurances will no longer look like value arguments when they did
before.
As consequence we also change how we compute CBV information for
arguments slightly. We now *always* determine the CBV convention
for arguments during tidy. Earlier in the pipeline we merely mark
functions as candidates for having their arguments treated as CBV.
As before the process is described in the relevant notes:
Note [CBV Function Ids]
Note [Attaching CBV Marks to ids]
Note [Never put `OtherCon` unfoldigns on lambda binders]
-------------------------
Metric Decrease:
T12425
T13035
T18223
T18223
T18923
MultiLayerModulesTH_OneShot
Metric Increase:
WWRec
-------------------------
|
| |
|
|
|
|
|
|
| |
Every Id was storing a boolean whether it could be levity-polymorphic.
This information is no longer needed since representation-checking
has been moved to the typechecker.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does three major things:
* Enforce the invariant that all strict fields must contain tagged
pointers.
* Try to predict the tag on bindings in order to omit tag checks.
* Allows functions to pass arguments unlifted (call-by-value).
The former is "simply" achieved by wrapping any constructor allocations with
a case which will evaluate the respective strict bindings.
The prediction is done by a new data flow analysis based on the STG
representation of a program. This also helps us to avoid generating
redudant cases for the above invariant.
StrictWorkers are created by W/W directly and SpecConstr indirectly.
See the Note [Strict Worker Ids]
Other minor changes:
* Add StgUtil module containing a few functions needed by, but
not specific to the tag analysis.
-------------------------
Metric Decrease:
T12545
T18698b
T18140
T18923
LargeRecord
Metric Increase:
LargeRecord
ManyAlternatives
ManyConstructors
T10421
T12425
T12707
T13035
T13056
T13253
T13253-spj
T13379
T15164
T18282
T18304
T18698a
T1969
T20049
T3294
T4801
T5321FD
T5321Fun
T783
T9233
T9675
T9961
T19695
WWRec
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PHASE 1: we never rewrite Concrete# evidence.
This patch migrates all the representation polymorphism checks to
the typechecker, using a new constraint form
Concrete# :: forall k. k -> TupleRep '[]
Whenever a type `ty` must be representation-polymorphic
(e.g. it is the type of an argument to a function), we emit a new
`Concrete# ty` Wanted constraint. If this constraint goes
unsolved, we report a representation-polymorphism error to the user.
The 'FRROrigin' datatype keeps track of the context of the
representation-polymorphism check, for more informative error messages.
This paves the way for further improvements, such as
allowing type families in RuntimeReps and improving the soundness
of typed Template Haskell. This is left as future work (PHASE 2).
fixes #17907 #20277 #20330 #20423 #20426
updates haddock submodule
-------------------------
Metric Decrease:
T5642
-------------------------
|
|
|
|
| |
fixes #19756, updates haddock submodule
|
|
|
|
|
|
|
|
|
|
| |
As #19882 pointed out, we were simply doing rubbish literals wrong.
(I'll refrain from explaining the wrong-ness here -- see the ticket.)
This patch fixes it by adding a Type (of kind RuntimeRep) as field of
LitRubbish, rather than [PrimRep].
The Note [Rubbish literals] in GHC.Types.Literal explains the details.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace uses of WARN macro with calls to:
warnPprTrace :: Bool -> SDoc -> a -> a
Remove the now unused HsVersions.h
Bump haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no reason to use CPP. __LINE__ and __FILE__ macros are now
better replaced with GHC's CallStack. As a bonus, assert error messages
now contain more information (function name, column).
Here is the mapping table (HasCallStack omitted):
* ASSERT: assert :: Bool -> a -> a
* MASSERT: massert :: Bool -> m ()
* ASSERTM: assertM :: m Bool -> m ()
* ASSERT2: assertPpr :: Bool -> SDoc -> a -> a
* MASSERT2: massertPpr :: Bool -> SDoc -> m ()
* ASSERTM2: assertPprM :: m Bool -> SDoc -> m ()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CorePrepProv is only created in CorePrep, so I thought it wouldn't be
needed in IfaceUnivCoProv. But actually IfaceSyn is used during
pretty-printing, and we can certainly pretty-print things after
CorePrep as #19768 showed.
So the simplest thing is to represent CorePrepProv in IfaceSyn.
To improve what Lint can do I also added a boolean to CorePrepProv, to
record whether it is homogeneously kinded or not. It is introduced in
two distinct ways (see Note [Unsafe coercions] in GHC.CoreToStg.Prep),
one of which may be hetero-kinded (e.g. Int ~ Int#) beause it is
casting a divergent expression; but the other is not. The boolean
keeps track.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19597, we also settled on the following renamings:
* `idStrictness` -> `idDmdSig`,
`strictnessInfo` -> `dmdSigInfo`,
`HsStrictness` -> `HsDmdSig`
* `idCprInfo` -> `idCprSig`,
`cprInfo` -> `cprSigInfo`,
`HsCpr` -> `HsCprSig`
Fixes #19597.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19194 mpickering detailed that there are a LOT of allocations
of IfaceTyConInfo:
There are just two main cases: IfaceTyConInfo IsPromoted IfaceNormalTyCon
and IfaceTyConInfo NotPromoted IfaceNormalTyCon. These should be made into
CAFs and shared. From my analysis, the most common case is
IfaceTyConInfo NotPromoted IfaceNormalTyCon (53 000)
then IfaceTyConInfo IsPromoted IfaceNormalTyCon (28 000).
This patch makes it so these are properly shared by using a smart
constructor.
Fixes #19194.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 2a94228 dramatically simplified the implementation and improved
the performance of COMPLETE sets while making them applicable in more
scenarios at the same time.
But it turned out that there was a change in semantics that (to me
unexpectedly) broke users' expectations (see #14422): They relied on the
"type signature" of a COMPLETE pragma to restrict the scrutinee types of
a pattern match for which they are applicable.
This patch brings back that filtering, so the semantics is the same as
it was in GHC 9.0.
See the updated Note [Implementation of COMPLETE pragmas].
There are a few testsuite output changes (`completesig13`, `T14422`)
which assert this change.
Co-authored-by: Sebastian Graf <sebastian.graf@kit.edu>
|
|
|
|
|
|
| |
Alt, AnnAlt and IfaceAlt were using triples. This patch makes them use
dedicated types so that we can try to make some fields strict (for
example) in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As outlined in #18903, interleaving usage and strictness demands not
only means a more compact demand representation, but also allows us to
express demands that we weren't easily able to express before.
Call demands are *relative* in the sense that a call demand `Cn(cd)`
on `g` says "`g` is called `n` times. *Whenever `g` is called*, the
result is used according to `cd`". Example from #18903:
```hs
h :: Int -> Int
h m =
let g :: Int -> (Int,Int)
g 1 = (m, 0)
g n = (2 * n, 2 `div` n)
{-# NOINLINE g #-}
in case m of
1 -> 0
2 -> snd (g m)
_ -> uncurry (+) (g m)
```
Without the interleaved representation, we would just get `L` for the
strictness demand on `g`. Now we are able to express that whenever
`g` is called, its second component is used strictly in denoting `g`
by `1C1(P(1P(U),SP(U)))`. This would allow Nested CPR to unbox the
division, for example.
Fixes #18903.
While fixing regressions, I also discovered and fixed #18957.
Metric Decrease:
T13253-spj
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was working on making DynFlags stateless (#17957), especially by
storing loaded plugins into HscEnv instead of DynFlags. It turned out to
be complicated because HscEnv is in GHC.Driver.Types but LoadedPlugin
isn't: it is in GHC.Driver.Plugins which depends on GHC.Driver.Types. I
didn't feel like introducing yet another hs-boot file to break the loop.
Additionally I remember that while we introduced the module hierarchy
(#13009) we talked about splitting GHC.Driver.Types because it contained
various unrelated types and functions, but we never executed. I didn't
feel like making GHC.Driver.Types bigger with more unrelated Plugins
related types, so finally I bit the bullet and split GHC.Driver.Types.
As a consequence this patch moves a lot of things. I've tried to put
them into appropriate modules but nothing is set in stone.
Several other things moved to avoid loops.
* Removed Binary instances from GHC.Utils.Binary for random compiler
things
* Moved Typeable Binary instances into GHC.Utils.Binary.Typeable: they
import a lot of things that users of GHC.Utils.Binary don't want to
depend on.
* put everything related to Units/Modules under GHC.Unit:
GHC.Unit.Finder, GHC.Unit.Module.{ModGuts,ModIface,Deps,etc.}
* Created several modules under GHC.Types: GHC.Types.Fixity, SourceText,
etc.
* Split GHC.Utils.Error (into GHC.Types.Error)
* Finally removed GHC.Driver.Types
Note that this patch doesn't put loaded plugins into HscEnv. It's left
for another patch.
Bump haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By not attaching COMPLETE pragmas with a particular TyCon and instead
assume that every COMPLETE pragma is applicable everywhere, we can
drastically simplify the logic that tries to initialise available
COMPLETE sets of a variable during the pattern-match checking process,
as well as fixing a few bugs.
Of course, we have to make sure not to report any of the
ill-typed/unrelated COMPLETE sets, which came up in a few regression
tests.
In doing so, we fix #17207, #18277 and #14422.
There was a metric decrease in #18478 by ~20%.
Metric Decrease:
T18478
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, associated type family defaults were validity-checked
during typechecking. Unfortunately, the error messages that these
checks produce run the risk of printing knot-tied type constructors,
which will cause GHC to diverge. In order to preserve the current
error message's descriptiveness, this patch postpones these validity
checks until after typechecking, which are now located in the new
function `GHC.Tc.Validity.checkValidAssocTyFamDeflt`.
Fixes #18648.
|
|
|
|
|
| |
This adds a new printing flag `sdocPrintTypeAbbreviations` that is used
specifically to avoid ghci printing 'type (->) = (->)' and 'type Type = Type'.
|
|
|
|
|
|
|
|
|
| |
- put panic related functions into GHC.Utils.Panic
- put trace related functions using DynFlags in GHC.Driver.Ppr
One step closer making Outputable fully independent of DynFlags.
Bump haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates haddock comments only.
This patch focuses to update for hyperlinks in GHC API's haddock comments,
because broken links especially discourage newcomers.
This includes the following hierarchies:
- GHC.Iface.*
- GHC.Llvm.*
- GHC.Rename.*
- GHC.Tc.*
- GHC.HsToCore.*
- GHC.StgToCmm.*
- GHC.CmmToAsm.*
- GHC.Runtime.*
- GHC.Unit.*
- GHC.Utils.*
- GHC.SysTools.*
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step towards implementation of the linear types proposal
(https://github.com/ghc-proposals/ghc-proposals/pull/111).
It features
* A language extension -XLinearTypes
* Syntax for linear functions in the surface language
* Linearity checking in Core Lint, enabled with -dlinear-core-lint
* Core-to-core passes are mostly compatible with linearity
* Fields in a data type can be linear or unrestricted; linear fields
have multiplicity-polymorphic constructors.
If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
The following items are not yet supported:
* a # m -> b syntax (only prefix FUN is supported for now)
* Full multiplicity inference (multiplicities are really only checked)
* Decent linearity error messages
* Linear let, where, and case expressions in the surface language
(each of these currently introduce the unrestricted variant)
* Multiplicity-parametric fields
* Syntax for annotating lambda-bound or let-bound with a multiplicity
* Syntax for non-linear/multiple-field-multiplicity records
* Linear projections for records with a single linear field
* Linear pattern synonyms
* Multiplicity coercions (test LinearPolyType)
A high-level description can be found at
https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Implementation
Following the link above you will find a description of the changes made to Core.
This commit has been authored by
* Richard Eisenberg
* Krzysztof Gogolewski
* Matthew Pickering
* Arnaud Spiwack
With contributions from:
* Mark Barbone
* Alexander Vershilov
Updates haddock submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Store LambdaFormInfos of exported Ids in interface files
- Use them in importing modules
This is for optimization purposes: if we know LambdaFormInfo of imported
Ids we can generate more efficient calling code, see `getCallMethod`.
Exporting (putting them in interface files or in ModDetails) and
importing (reading them from interface files) are both optional. We
don't assume known LambdaFormInfos anywhere and do not change how we
call Ids with unknown LambdaFormInfos.
Runtime, allocation, and residency numbers when building
Cabal-the-library (commit 0d4ee7ba3):
(Log and .hp files are in the MR: !2842)
| | GHC HEAD | This patch | Diff |
|-----|----------|------------|----------------|
| -O0 | 0:35.89 | 0:34.10 | -1.78s, -4.98% |
| -O1 | 2:24.01 | 2:23.62 | -0.39s, -0.27% |
| -O2 | 2:52.23 | 2:51.35 | -0.88s, -0.51% |
| | GHC HEAD | This patch | Diff |
|-----|-----------------|-----------------|----------------------------|
| -O0 | 54,843,608,416 | 54,878,769,544 | +35,161,128 bytes, +0.06% |
| -O1 | 227,136,076,400 | 227,569,045,168 | +432,968,768 bytes, +0.19% |
| -O2 | 266,147,063,296 | 266,749,643,440 | +602,580,144 bytes, +0.22% |
NOTE: Residency is measured with extra runtime args: `-i0 -h` which effectively
turn all GCs into major GCs, and do GC more often.
| | GHC HEAD | This patch | Diff |
|-----|----------------------------|------------------------------|----------------------------|
| -O0 | 410,284,000 (910 samples) | 411,745,008 (906 samples) | +1,461,008 bytes, +0.35% |
| -O1 | 928,580,856 (2109 samples) | 943,506,552 (2103 samples) | +14,925,696 bytes, +1.60% |
| -O2 | 993,951,352 (2549 samples) | 1,010,156,328 (2545 samples) | +16,204,9760 bytes, +1.63% |
NoFib results:
--------------------------------------------------------------------------------
Program Size Allocs Instrs Reads Writes
--------------------------------------------------------------------------------
CS 0.0% 0.0% +0.0% +0.0% +0.0%
CSD 0.0% 0.0% 0.0% +0.0% +0.0%
FS 0.0% 0.0% +0.0% +0.0% +0.0%
S 0.0% 0.0% +0.0% +0.0% +0.0%
VS 0.0% 0.0% +0.0% +0.0% +0.0%
VSD 0.0% 0.0% +0.0% +0.0% +0.1%
VSM 0.0% 0.0% +0.0% +0.0% +0.0%
anna 0.0% 0.0% -0.3% -0.8% -0.0%
ansi 0.0% 0.0% -0.0% -0.0% 0.0%
atom 0.0% 0.0% -0.0% -0.0% 0.0%
awards 0.0% 0.0% -0.1% -0.3% 0.0%
banner 0.0% 0.0% -0.0% -0.0% -0.0%
bernouilli 0.0% 0.0% -0.0% -0.0% -0.0%
binary-trees 0.0% 0.0% -0.0% -0.0% +0.0%
boyer 0.0% 0.0% -0.0% -0.0% 0.0%
boyer2 0.0% 0.0% -0.0% -0.0% 0.0%
bspt 0.0% 0.0% -0.0% -0.2% 0.0%
cacheprof 0.0% 0.0% -0.1% -0.4% +0.0%
calendar 0.0% 0.0% -0.0% -0.0% 0.0%
cichelli 0.0% 0.0% -0.9% -2.4% 0.0%
circsim 0.0% 0.0% -0.0% -0.0% 0.0%
clausify 0.0% 0.0% -0.1% -0.3% 0.0%
comp_lab_zift 0.0% 0.0% -0.0% -0.0% +0.0%
compress 0.0% 0.0% -0.0% -0.0% -0.0%
compress2 0.0% 0.0% -0.0% -0.0% 0.0%
constraints 0.0% 0.0% -0.1% -0.2% -0.0%
cryptarithm1 0.0% 0.0% -0.0% -0.0% 0.0%
cryptarithm2 0.0% 0.0% -1.4% -4.1% -0.0%
cse 0.0% 0.0% -0.0% -0.0% -0.0%
digits-of-e1 0.0% 0.0% -0.0% -0.0% -0.0%
digits-of-e2 0.0% 0.0% -0.0% -0.0% -0.0%
dom-lt 0.0% 0.0% -0.1% -0.2% 0.0%
eliza 0.0% 0.0% -0.5% -1.5% 0.0%
event 0.0% 0.0% -0.0% -0.0% -0.0%
exact-reals 0.0% 0.0% -0.1% -0.3% +0.0%
exp3_8 0.0% 0.0% -0.0% -0.0% -0.0%
expert 0.0% 0.0% -0.3% -1.0% -0.0%
fannkuch-redux 0.0% 0.0% +0.0% +0.0% +0.0%
fasta 0.0% 0.0% -0.0% -0.0% +0.0%
fem 0.0% 0.0% -0.0% -0.0% 0.0%
fft 0.0% 0.0% -0.0% -0.0% 0.0%
fft2 0.0% 0.0% -0.0% -0.0% 0.0%
fibheaps 0.0% 0.0% -0.0% -0.0% +0.0%
fish 0.0% 0.0% 0.0% -0.0% +0.0%
fluid 0.0% 0.0% -0.4% -1.2% +0.0%
fulsom 0.0% 0.0% -0.0% -0.0% 0.0%
gamteb 0.0% 0.0% -0.1% -0.3% 0.0%
gcd 0.0% 0.0% -0.0% -0.0% 0.0%
gen_regexps 0.0% 0.0% -0.0% -0.0% -0.0%
genfft 0.0% 0.0% -0.0% -0.0% 0.0%
gg 0.0% 0.0% -0.0% -0.0% +0.0%
grep 0.0% 0.0% -0.0% -0.0% -0.0%
hidden 0.0% 0.0% -0.1% -0.4% -0.0%
hpg 0.0% 0.0% -0.2% -0.5% +0.0%
ida 0.0% 0.0% -0.0% -0.0% +0.0%
infer 0.0% 0.0% -0.3% -0.8% -0.0%
integer 0.0% 0.0% -0.0% -0.0% +0.0%
integrate 0.0% 0.0% -0.0% -0.0% 0.0%
k-nucleotide 0.0% 0.0% -0.0% -0.0% +0.0%
kahan 0.0% 0.0% -0.0% -0.0% +0.0%
knights 0.0% 0.0% -2.2% -5.4% 0.0%
lambda 0.0% 0.0% -0.6% -1.8% 0.0%
last-piece 0.0% 0.0% -0.0% -0.0% 0.0%
lcss 0.0% 0.0% -0.0% -0.1% 0.0%
life 0.0% 0.0% -0.0% -0.1% 0.0%
lift 0.0% 0.0% -0.2% -0.6% +0.0%
linear 0.0% 0.0% -0.0% -0.0% -0.0%
listcompr 0.0% 0.0% -0.0% -0.0% 0.0%
listcopy 0.0% 0.0% -0.0% -0.0% 0.0%
maillist 0.0% 0.0% -0.1% -0.3% +0.0%
mandel 0.0% 0.0% -0.0% -0.0% 0.0%
mandel2 0.0% 0.0% -0.0% -0.0% -0.0%
mate +0.0% 0.0% -0.0% -0.0% -0.0%
minimax 0.0% 0.0% -0.2% -1.0% 0.0%
mkhprog 0.0% 0.0% -0.1% -0.2% -0.0%
multiplier 0.0% 0.0% -0.0% -0.0% -0.0%
n-body 0.0% 0.0% -0.0% -0.0% +0.0%
nucleic2 0.0% 0.0% -0.1% -0.2% 0.0%
para 0.0% 0.0% -0.0% -0.0% -0.0%
paraffins 0.0% 0.0% -0.0% -0.0% 0.0%
parser 0.0% 0.0% -0.2% -0.7% 0.0%
parstof 0.0% 0.0% -0.0% -0.0% +0.0%
pic 0.0% 0.0% -0.0% -0.0% 0.0%
pidigits 0.0% 0.0% +0.0% +0.0% +0.0%
power 0.0% 0.0% -0.2% -0.6% +0.0%
pretty 0.0% 0.0% -0.0% -0.0% -0.0%
primes 0.0% 0.0% -0.0% -0.0% 0.0%
primetest 0.0% 0.0% -0.0% -0.0% -0.0%
prolog 0.0% 0.0% -0.3% -1.1% 0.0%
puzzle 0.0% 0.0% -0.0% -0.0% 0.0%
queens 0.0% 0.0% -0.0% -0.0% +0.0%
reptile 0.0% 0.0% -0.0% -0.0% 0.0%
reverse-complem 0.0% 0.0% -0.0% -0.0% +0.0%
rewrite 0.0% 0.0% -0.7% -2.5% -0.0%
rfib 0.0% 0.0% -0.0% -0.0% 0.0%
rsa 0.0% 0.0% -0.0% -0.0% 0.0%
scc 0.0% 0.0% -0.1% -0.2% -0.0%
sched 0.0% 0.0% -0.0% -0.0% -0.0%
scs 0.0% 0.0% -1.0% -2.6% +0.0%
simple 0.0% 0.0% +0.0% -0.0% +0.0%
solid 0.0% 0.0% -0.0% -0.0% 0.0%
sorting 0.0% 0.0% -0.6% -1.6% 0.0%
spectral-norm 0.0% 0.0% +0.0% 0.0% +0.0%
sphere 0.0% 0.0% -0.0% -0.0% -0.0%
symalg 0.0% 0.0% -0.0% -0.0% +0.0%
tak 0.0% 0.0% -0.0% -0.0% 0.0%
transform 0.0% 0.0% -0.0% -0.0% 0.0%
treejoin 0.0% 0.0% -0.0% -0.0% 0.0%
typecheck 0.0% 0.0% -0.0% -0.0% +0.0%
veritas +0.0% 0.0% -0.2% -0.4% +0.0%
wang 0.0% 0.0% -0.0% -0.0% 0.0%
wave4main 0.0% 0.0% -0.0% -0.0% -0.0%
wheel-sieve1 0.0% 0.0% -0.0% -0.0% -0.0%
wheel-sieve2 0.0% 0.0% -0.0% -0.0% +0.0%
x2n1 0.0% 0.0% -0.0% -0.0% -0.0%
--------------------------------------------------------------------------------
Min 0.0% 0.0% -2.2% -5.4% -0.0%
Max +0.0% 0.0% +0.0% +0.0% +0.1%
Geometric Mean -0.0% -0.0% -0.1% -0.3% +0.0%
Metric increases micro benchmarks tracked in #17686:
Metric Increase:
T12150
T12234
T12425
T13035
T5837
T6048
T9233
Co-authored-by: Andreas Klebinger <klebinger.andreas@gmx.at>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates comments only.
This patch replaces leaf module names according to new module
hierarchy [1][2] as followings:
* Expand leaf names to easily find the module path:
for instance, `Id.hs` to `GHC.Types.Id`.
* Modify leaf names according to new module hierarchy:
for instance, `Convert.hs` to `GHC.ThToHs`.
* Fix typo:
for instance, `GHC.Core.TyCo.Rep.hs` to `GHC.Core.TyCo.Rep`
See also !3375
[1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
[2]: https://gitlab.haskell.org/ghc/ghc/issues/13009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementation for Ticket #16393.
Explicit specificity allows users to manually create inferred type variables,
by marking them with braces.
This way, the user determines which variables can be instantiated through
visible type application.
The additional syntax is included in the parser, allowing users to write
braces in type variable binders (type signatures, data constructors etc).
This information is passed along through the renamer and verified in the
type checker.
The AST for type variable binders, data constructors, pattern synonyms,
partial signatures and Template Haskell has been updated to include the
specificity of type variables.
Minor notes:
- Bumps haddock submodule
- Disables pattern match checking in GHC.Iface.Type with GHC 8.8
|
|
|
|
|
|
|
| |
Introduce GHC.Unit.* hierarchy for everything concerning units, packages
and modules.
Update Haddock submodule
|
|
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* SysTools
* Parser
* GHC.Builtin
* GHC.Iface.Recomp
* Settings
Update Haddock submodule
Metric Decrease:
Naperian
parsing001
|
|
|
|
|
|
|
|
|
|
|
| |
* GHC.Core.Op => GHC.Core.Opt
* GHC.Core.Opt.Simplify.Driver => GHC.Core.Opt.Driver
* GHC.Core.Opt.Tidy => GHC.Core.Tidy
* GHC.Core.Opt.WorkWrap.Lib => GHC.Core.Opt.WorkWrap.Utils
As discussed in:
* https://mail.haskell.org/pipermail/ghc-devs/2020-April/018758.html
* https://gitlab.haskell.org/ghc/ghc/issues/13009#note_264650
|
|
|
|
| |
Update Haddock submodule
|
|
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
|
|
|
| |
Update submodule: haddock
|
|
|
|
|
|
|
|
| |
* GHC.Iface.Recomp: recompilation avoidance stuff
* GHC.Iface.Make: mkIface*
Moved `writeIfaceFile` into GHC.Iface.Load alongside `readIface` and
renamed it `writeIface` for consistency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IfaceIdInfo type is confusing: there's practically no difference between
`NoInfo` and `HasInfo []`. The comments say NoInfo is used when
-fomit-interface-pragmas is enabled, but we don't need to distinguish
`NoInfo` from `HasInfo []` in when reading the interface so the
distinction is not important.
This patch simplifies the type by removing NoInfo. When we have no info
we use an empty list.
With this change we no longer read the info list lazily when reading an
IfaceInfoItem, but when reading an IfaceId the ifIdInfo field is
read lazily, so I doubt this is going to be a problem.
|
|
|
|
| |
Update haddock submodule
|
|
|
|
| |
submodule updates: nofib, haddock
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove several uses of `sdocWithDynFlags`. The remaining ones are mostly
CodeGen related (e.g. depend on target platform constants) and will be
fixed separately.
Metric Decrease:
T12425
T9961
WWRec
T1969
T14683
|