| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19969 we discovered that GHC has has a bug *forever* that means it
sometimes essentially discarded INLINE pragams. This happened when you have
* Two more more mutually recursive functions
* Some of which (presumably not all!) have an INLINE pragma
* Completely monomorphic.
This hits a particular case in GHC.HsToCore.Binds.dsAbsBinds, which was
simply wrong -- it put the INLINE pragma on the wrong binder.
This patch fixes the bug, rather easily, by adjusting the
no-tyvar, no-dict case of GHC.HsToCore.Binds.dsAbsBinds.
I also discovered that the GHC.Core.Opt.Pipeline.shortOutIndirections
was not doing a good job for
{-# INLINE lcl_id #-}
lcl_id = BIG
gbl_id = lcl_id
Here we want to transfer the stable unfolding to gbl_id (we do), but
we also want to remove it from lcl_id (we were not doing that).
Otherwise both Ids have large stable unfoldings. Easily fixed.
Note [Transferring IdInfo] explains.
|
|
|
|
| |
fixes #19756, updates haddock submodule
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For reasons described in GHC.Core.Opt.Simplify
Historical Note [Case binders and join points],
we used to keep a Core unfolding in one of the lambda-binders
for a join point. But this was always a gross hack -- it's
very odd to have an unfolding in a lambda binder, that refers to
earlier lambda binders.
The hack bit us in various ways:
* Most seriously, it is incompatible with linear types in Core.
* It complicated demand analysis, and could worsen results
* It required extra care in the simplifier (simplLamBinder)
* It complicated !5641 (look for "join binder unfoldings")
So this patch just removes the hack. Happily, doind so turned out to
have no effect on performance.
|
|
|
|
|
|
|
|
|
|
| |
Now that we hash object files to decide when to recompile due to TH,
this can make a big difference as each interface file in a project will
contain reference to the object files of all package dependencies.
Especially when these are statically linked, hashing them can add up.
The cache is invalidated when `depanalPartial` is called, like the
normal finder cache.
|
| |
|
|
|
|
| |
asynchronous.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`GHC.Hs.Syn.Type`
The existing `hsPatType`, `hsLPatType` and `hsLitType` functions have also been
moved to this module
This is a less ambitious take on the same problem that !2182 and !3866
attempt to solve. Rather than have the `hsExprType` function attempt to
efficiently compute the `Type` of every subexpression in an `HsExpr`, this
simply computes the overall `Type` of a single `HsExpr`.
- Explicitly forbids the `SplicePat` `HsIPVar`, `HsBracket`, `HsRnBracketOut`
and `HsTcBracketOut` constructors during the typechecking phase by using
`Void` as the TTG extension field
- Also introduces `dataConCantHappen` as a domain specific alternative to `absurd`
to handle cases where the TTG extension points forbid a constructor.
- Turns HIE file generation into a pure function that doesn't need access to the
`DsM` monad to compute types, but uses `hsExprType` instead.
- Computes a few more types during HIE file generation
- Makes GHCi's `:set +c` command also use `hsExprType` instead of going through
the desugarer to compute types.
Updates haddock submodule
Co-authored-by: Zubin Duggal <zubin.duggal@gmail.com>
|
|
|
|
|
|
|
|
| |
In (<|>) for ZipList, avoid processing the first argument twice (both as first
argument of (++) and for its length in drop count of the second argument).
Previously, the entire first argument was forced into memory, now (<|>) can run
in constant space even with long inputs.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is an attempt at reducing the number of dependencies of the Parser
(as reported by CountParserDeps). Modules in GHC.Parser.* don't import
GHC.Driver.Session directly anymore.
Sadly some GHC.Driver.* modules are still transitively imported and the
number of dependencies didn't decrease. But it's a step in the right
direction.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce LogFlags as a independent subset of DynFlags used for logging.
As a consequence in many places we don't have to pass both Logger and
DynFlags anymore.
The main reason for this refactoring is that I want to refactor the
systools interfaces: for now many systools functions use DynFlags both
to use the Logger and to fetch their parameters (e.g. ldInputs for the
linker). I'm interested in refactoring the way they fetch their
parameters (i.e. use dedicated XxxOpts data types instead of DynFlags)
for #19877. But if I did this refactoring before refactoring the Logger,
we would have duplicate parameters (e.g. ldInputs from DynFlags and
linkerInputs from LinkerOpts). Hence this patch first.
Some flags don't really belong to LogFlags because they are subsystem
specific (e.g. most DumpFlags). For example -ddump-asm should better be
passed in NCGConfig somehow. This patch doesn't fix this tight coupling:
the dump flags are part of the UI but they are passed all the way down
for example to infer the file name for the dumps.
Because LogFlags are a subset of the DynFlags, we must update the former
when the latter changes (not so often). As a consequence we now use
accessors to read/write DynFlags in HscEnv instead of using `hsc_dflags`
directly.
In the process I've also made some subsystems less dependent on DynFlags:
- CmmToAsm: by passing some missing flags via NCGConfig (see new fields
in GHC.CmmToAsm.Config)
- Core.Opt.*:
- by passing -dinline-check value into UnfoldingOpts
- by fixing some Core passes interfaces (e.g. CallArity, FloatIn)
that took DynFlags argument for no good reason.
- as a side-effect GHC.Core.Opt.Pipeline.doCorePass is much less
convoluted.
|
| |
|
|
|
|
|
|
|
| |
As noted in #10037, the `ioprof` test would change its stderr output
(specifically the stacktrace produced by `error`) depending upon
optimisation level. As the `error` backtrace is not the point of this
test, we now ignore the `stderr` output.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this (from #19824)
let t = ...big...
in ...(f t x)...
were `f` ignores its first argument. With luck f's wrapper will inline
thereby dropping `t`, but maybe not: the arguments to f all look boring.
So we pre-empt the problem by replacing t's RHS with an absent filler
during w/w. Simple and effective.
The main payload is the new `isAbsDmd` case in `tryWw`, but there are
some other minor refactorings:
* To implment this I had to refactor `mk_absent_let` to
`mkAbsentFiller`, which can be called from `tryWW`.
* wwExpr took both WwOpts and DynFlags which seems silly. I combined
them into one.
* I renamed the historical mkInineRule to mkWrapperUnfolding
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit:
commit c6faa42bfb954445c09c5680afd4fb875ef03758
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Mon Mar 9 10:20:42 2020 +0000
Avoid useless w/w split
This patch is just a tidy-up for the post-strictness-analysis
worker wrapper split. Consider
f x = x
Strictnesss analysis does not lead to a w/w split, so the
obvious thing is to leave it 100% alone. But actually, because
the RHS is small, we ended up adding a StableUnfolding for it.
There is some reason to do this if we choose /not/ do to w/w
on the grounds that the function is small. See
Note [Don't w/w inline small non-loop-breaker things]
But there is no reason if we would not have done w/w anyway.
This patch just moves the conditional to later. Easy.
turns out to have a bug in it. Instead of /moving/ the conditional,
I /duplicated/ it. Then in a subsequent unrelated tidy-up
(087ac4eb) I removed the second (redundant) test!
This patch does what I originally intended.
There is also a small refactoring in GHC.Core.Unfold, to make the
code clearer, but with no change in behaviour.
It does, however, have a generally good effect on compile times,
because we aren't dealing with so many silly stable unfoldings.
Here are the non-zero changes:
Metrics: compile_time/bytes allocated
-------------------------------------
Baseline
Test Metric value New value Change
---------------------------------------------------------------------------
ManyAlternatives(normal) ghc/alloc 791969344.0 792665048.0 +0.1%
ManyConstructors(normal) ghc/alloc 4351126824.0 4358303528.0 +0.2%
PmSeriesG(normal) ghc/alloc 50362552.0 50482208.0 +0.2%
PmSeriesS(normal) ghc/alloc 63733024.0 63619912.0 -0.2%
T10421(normal) ghc/alloc 121224624.0 119695448.0 -1.3% GOOD
T10421a(normal) ghc/alloc 85256392.0 83714224.0 -1.8%
T10547(normal) ghc/alloc 29253072.0 29258256.0 +0.0%
T10858(normal) ghc/alloc 189343152.0 187972328.0 -0.7%
T11195(normal) ghc/alloc 281208248.0 279727584.0 -0.5%
T11276(normal) ghc/alloc 141966952.0 142046224.0 +0.1%
T11303b(normal) ghc/alloc 46228360.0 46259024.0 +0.1%
T11545(normal) ghc/alloc 2663128768.0 2667412656.0 +0.2%
T11822(normal) ghc/alloc 138686944.0 138760176.0 +0.1%
T12227(normal) ghc/alloc 482836000.0 475421056.0 -1.5% GOOD
T12234(optasm) ghc/alloc 60710520.0 60781808.0 +0.1%
T12425(optasm) ghc/alloc 104089000.0 104022424.0 -0.1%
T12545(normal) ghc/alloc 1711759416.0 1705711528.0 -0.4%
T12707(normal) ghc/alloc 991541120.0 991921776.0 +0.0%
T13035(normal) ghc/alloc 108199872.0 108370704.0 +0.2%
T13056(optasm) ghc/alloc 414642544.0 412580384.0 -0.5%
T13253(normal) ghc/alloc 361701272.0 355838624.0 -1.6%
T13253-spj(normal) ghc/alloc 157710168.0 157397768.0 -0.2%
T13379(normal) ghc/alloc 370984400.0 371345888.0 +0.1%
T13701(normal) ghc/alloc 2439764144.0 2441351984.0 +0.1%
T14052(ghci) ghc/alloc 2154090896.0 2156671400.0 +0.1%
T15164(normal) ghc/alloc 1478517688.0 1440317696.0 -2.6% GOOD
T15630(normal) ghc/alloc 178053912.0 172489808.0 -3.1%
T16577(normal) ghc/alloc 7859948896.0 7854524080.0 -0.1%
T17516(normal) ghc/alloc 1271520128.0 1202096488.0 -5.5% GOOD
T17836(normal) ghc/alloc 1123320632.0 1123922480.0 +0.1%
T17836b(normal) ghc/alloc 54526280.0 54576776.0 +0.1%
T17977b(normal) ghc/alloc 42706752.0 42730544.0 +0.1%
T18140(normal) ghc/alloc 108834568.0 108693816.0 -0.1%
T18223(normal) ghc/alloc 5539629264.0 5579500872.0 +0.7%
T18304(normal) ghc/alloc 97589720.0 97196944.0 -0.4%
T18478(normal) ghc/alloc 770755472.0 771232888.0 +0.1%
T18698a(normal) ghc/alloc 408691160.0 374364992.0 -8.4% GOOD
T18698b(normal) ghc/alloc 492419768.0 458809408.0 -6.8% GOOD
T18923(normal) ghc/alloc 72177032.0 71368824.0 -1.1%
T1969(normal) ghc/alloc 803523496.0 804655112.0 +0.1%
T3064(normal) ghc/alloc 198411784.0 198608512.0 +0.1%
T4801(normal) ghc/alloc 312416688.0 312874976.0 +0.1%
T5321Fun(normal) ghc/alloc 325230680.0 325474448.0 +0.1%
T5631(normal) ghc/alloc 592064448.0 593518968.0 +0.2%
T5837(normal) ghc/alloc 37691496.0 37710904.0 +0.1%
T783(normal) ghc/alloc 404629536.0 405064432.0 +0.1%
T9020(optasm) ghc/alloc 266004608.0 266375592.0 +0.1%
T9198(normal) ghc/alloc 49221336.0 49268648.0 +0.1%
T9233(normal) ghc/alloc 913464984.0 742680256.0 -18.7% GOOD
T9675(optasm) ghc/alloc 552296608.0 466322000.0 -15.6% GOOD
T9872a(normal) ghc/alloc 1789910616.0 1793924472.0 +0.2%
T9872b(normal) ghc/alloc 2315141376.0 2310338056.0 -0.2%
T9872c(normal) ghc/alloc 1840422424.0 1841567224.0 +0.1%
T9872d(normal) ghc/alloc 556713248.0 556838432.0 +0.0%
T9961(normal) ghc/alloc 383809160.0 384601600.0 +0.2%
WWRec(normal) ghc/alloc 773751272.0 753949608.0 -2.6% GOOD
Residency goes down too:
Metrics: compile_time/max_bytes_used
------------------------------------
Baseline
Test Metric value New value Change
-----------------------------------------------------------
T10370(optasm) ghc/max 42058448.0 39481672.0 -6.1%
T11545(normal) ghc/max 43641392.0 43634752.0 -0.0%
T15304(normal) ghc/max 29895824.0 29439032.0 -1.5%
T15630(normal) ghc/max 8822568.0 8772328.0 -0.6%
T18698a(normal) ghc/max 13882536.0 13787112.0 -0.7%
T18698b(normal) ghc/max 14714112.0 13836408.0 -6.0%
T1969(normal) ghc/max 24724128.0 24733496.0 +0.0%
T3064(normal) ghc/max 14041152.0 14034768.0 -0.0%
T3294(normal) ghc/max 32769248.0 32760312.0 -0.0%
T9630(normal) ghc/max 41605120.0 41572184.0 -0.1%
T9675(optasm) ghc/max 18652296.0 17253480.0 -7.5%
Metric Decrease:
T10421
T12227
T15164
T17516
T18698a
T18698b
T9233
T9675
WWRec
Metric Increase:
T12545
|
|
|
|
| |
[ci skip]
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In which we add a new code generator to the Glasgow Haskell
Compiler. This codegen supports ELF and Mach-O targets, thus covering
Linux, macOS, and BSDs in principle. It was tested only on macOS and
Linux. The NCG follows a similar structure as the other native code
generators we already have, and should therfore be realtively easy to
follow.
It supports most of the features required for a proper native code
generator, but does not claim to be perfect or fully optimised. There
are still opportunities for optimisations.
Metric Decrease:
ManyAlternatives
ManyConstructors
MultiLayerModules
PmSeriesG
PmSeriesS
PmSeriesT
PmSeriesV
T10421
T10421a
T10858
T11195
T11276
T11303b
T11374
T11822
T12227
T12545
T12707
T13035
T13253
T13253-spj
T13379
T13701
T13719
T14683
T14697
T15164
T15630
T16577
T17096
T17516
T17836
T17836b
T17977
T17977b
T18140
T18282
T18304
T18478
T18698a
T18698b
T18923
T1969
T3064
T5030
T5321FD
T5321Fun
T5631
T5642
T5837
T783
T9198
T9233
T9630
T9872d
T9961
WWRec
Metric Increase:
T4801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit expands the old Note [Type variable cycles in Givens] to apply
as well to Deriveds. See the Note for details and examples. This fixes a
regression introduced by my earlier commit that killed off the flattener in
favor of the rewriter.
A few other things happened along the way:
* unifyTest was renamed to touchabilityTest, because that's what it does.
* isInsolubleOccursCheck was folded into checkTypeEq, which does much of the
same work. To get this to work out, though, we need to keep more careful
track of what errors we spot in checkTypeEq, and so CheckTyEqResult has
become rather more glorious.
* A redundant Note or two was eliminated.
* Kill off occCheckForErrors; due to Note [Rewriting synonyms], the
extra occCheckExpand here is always redundant.
* Store blocked equalities separately from other inerts; less stuff
to look through when kicking out.
Close #19682.
test case: typecheck/should_compile/T19682{,b}
|
| |
|
|
|
|
|
|
|
|
| |
- Move 'count-deps' into 'ghc/utils' so that it can be called standalone.
- Move 'testsuite/tests/parser/should_run/' tests 'CountParserDeps' and
'CountAstDeps' to 'testsuite/tests/count-deps' and reimplement in terms
of calling the utility
- Document how to use 'count-deps' in 'ghc/utils/count-deps/README'
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ensure that division wrappers are INLINE
* make div/mod/divMod call quot/rem/quotRem (same code)
* this ensures that the quotRemWordN# primitive is used to implement
divMod (it wasn't the case for sized Words)
* make first argument strict for Natural and Integer (similarly to other
numeric types)
|
|
|
|
| |
Fixes #17817
|
|
|
|
|
|
|
|
|
|
|
| |
This commit replaces the PsUnknownMessage diagnostics over at
`GHC.Parser.Header` with a new `PsHeaderMessage` type (part of
the more general `PsMessage`), so that we can throw parser header's
errors which can be correctly caught by `GHC.Driver.Pipeline.preprocess`
and rewrapped (correctly) as Driver messages (using the
`DriverPsHeaderMessage`).
This gets rid of the nasty compiler crash as part of #19923.
|
|
|
|
|
| |
This patch adds OverloadedRecordDot and OverloadedRecordUpdate in
9.2.1's release note.
|
|
|
|
|
|
|
|
| |
The flag is called `-Wprepositive-qualified-module`, not
`-Wprepositive-qualified-syntax`.
Use the `:ghc-flag:` syntax, which would have caught the mistake in the first
place.
|
|
|
|
|
|
|
|
|
| |
* Add a Note to clarify RttiTypes.
* Don't call `quantifyType` at all the call sites of `check2`.
* Simplyfy arguments of functions `Inspect.hs:check1` and `Inspect.hs:check2`.
- `check1` only uses the two lists of type variables, but not the types.
- `check2` only uses the two types, but not the lists of type variables.
* In `Inspect.hs:check2` send only the tau part of the type to `tcSplitTyConApp_maybe`.
|
|
|
|
|
|
|
|
|
|
|
| |
This commit converts a bunch of HsToCore (Ds) messages to use the new
GHC's diagnostic message infrastructure. In particular the DsMessage
type has been expanded with a lot of type constructors, each
encapsulating a particular error and warning emitted during desugaring.
Due to the fact that levity polymorphism checking can happen both at the
Ds and at the TcRn level, a new `TcLevityCheckDsMessage` constructor has
been added to the `TcRnMessage` type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch comprises of four different but closely related ideas. The
net result is fixing a large number of open issues with the driver
whilst making it simpler to understand.
1. Use the hash of the source file to determine whether the source file
has changed or not. This makes the recompilation checking more robust to
modern build systems which are liable to copy files around changing
their modification times.
2. Remove the concept of a "stable module", a stable module was one
where the object file was older than the source file, and all transitive
dependencies were also stable. Now we don't rely on the modification
time of the source file, the notion of stability is moot.
3. Fix TH/plugin recompilation after the removal of stable modules. The
TH recompilation check used to rely on stable modules. Now there is a
uniform and simple way, we directly track the linkables which were
loaded into the interpreter whilst compiling a module. This is an
over-approximation but more robust wrt package dependencies changing.
4. Fix recompilation checking for dynamic object files. Now we actually
check if the dynamic object file exists when compiling with -dynamic-too
Fixes #19774 #19771 #19758 #17434 #11556 #9121 #8211 #16495 #7277 #16093
|
|
|
|
|
|
|
|
| |
The tests `CountParserDeps.hs` and `CountAstDeps.hs` are implemented
by calling `CountDeps`. In this MR, `CountDeps.printDeps` is updated
such tat by uncommenting a line, you can print a module's dependency
graph showing what includes what. The output is in a format suitable
for use with graphviz.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the now historic part of `NOTE [aBSENT_ERROR_ID]` explains, we used to have
`exprIsHNF` respond True to `absentError` and give it a non-bottoming demand
signature, in order to perform case-to-let on certain `case`s we used to emit
that scrutinised `absentError` (Urgh).
What changed, why don't we emit these questionable absent errors anymore?
The absent errors in question filled in for binders that would end up in
strict fields after being seq'd. Apparently, the old strictness analyser would
give these binders an absent demand, but today we give them head-strict demand
`1A` and thus don't replace with absent errors at all.
This fixes items (1) and (2) of #19853.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When compiling Agda we entered into an infinite loop as the stopping
condition was a bit wrong in hptSomeModulesBelow.
The bad situation was something like
* We would see module A (NotBoot) and follow it dependencies
* Later on we would encounter A (Boot) and follow it's dependencies,
because the lookup would not match A (NotBoot) and A (IsBoot)
* Somewhere in A (Boot)s dependencies, A (Boot) would appear again and
lead us into an infinite loop.
Now the state marks whether we have been both variants (IsBoot and
NotBoot) so we don't follow dependencies for A (Boot) many times.
|
|
|
|
|
| |
This causes hadrian to be built twice because the second time uses a
different index state.
|
| |
|
|
|
|
|
|
|
|
|
| |
The rule before decided to build the whole stage1 compiler, but this was
unecessary as we were just missing one header file which can be
generated directly by calling configure.
Before: 18 minutes
After: 54s
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, GHC used to silently accept programs such as the
following:
data R where
D1 :: { d1 :: Int } %1 -> R
The %1 annotation was completely ignored. Now it is a proper error.
One remaining issue is that in the error message (⊸) turns
into (%1 ->). This is to be corrected with upcoming exactprint updates.
|
| |
|
| |
|
|
|
|
|
|
|
| |
* For primops from `GHC.Prim` lookup the HValues in `GHC.PrimopWrappers`.
* Add short error messages if a user tries to use a *Non-Id* value or a
`pseudoop` in a `:print`, `:sprint` or `force`command.
* Add additional test cases for `Magic Ids`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sequencing of monadic effects in foldlM and foldrM was described as
respectively right-associative and left-associative, but this could be
confusing, as in essence we're just composing Kleisli arrows, whose
composition is simply associative.
What matters therefore is the order of sequencing of effects, which
can be described more clearly without dragging in associativity as
such.
This avoids describing these folds as being both left-to-right and
right-to-left depending on whether we're tracking effects or operator
application. The new text should be easier to understand.
|
| |
|