| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the BoxedRep proposal, refactoring the `RuntimeRep`
hierarchy from:
```haskell
data RuntimeRep = LiftedPtrRep | UnliftedPtrRep | ...
```
to
```haskell
data RuntimeRep = BoxedRep Levity | ...
data Levity = Lifted | Unlifted
```
Updates binary, haddock submodules.
Closes #17526.
Metric Increase:
T12545
|
| |
|
|
|
|
| |
This enables a registerised build for the riscv64 architecture.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses points (1a) and (1b) of #19165.
- Move mkFailExpr to HsToCore/Utils, as it can be shared
- Desugar incomplete patterns and holes to an empty case,
as in Note [Incompleteness and linearity]
- Enable linear linting of desugarer output
- Mark MultConstructor as broken. It fails Lint, but I'd like to fix this
separately.
Metric Decrease:
T6048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Part of #17804.
|
|
|
|
|
|
|
|
|
|
| |
During testing it was observed that quite a few info tables were not
being given locations (due to not being assigned source locations,
because they were not enclosed by a source note). We can at least give
the module name and type for such closures even if no more accurate
source information.
Especially for constructors this helps find them in the STG dumps.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The `whereFrom` function provides a Haskell interface for using the
information created by `-finfo-table-map`. Given a Haskell value, the
info table address will be passed to the `lookupIPE` function in order
to attempt to find the source location information for that particular closure.
At the moment it's not possible to distinguish the absense of the map
and a failed lookup.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `-fdistinct-constructor-tables` flag will generate a fresh info
table for the usage of any data constructor. This is useful for
debugging as now by inspecting the info table, you can determine which
usage of a constructor caused that allocation rather than the old
situation where the info table always mapped to the definition site of
the data constructor which is useless.
In conjunction with `-hi` and `-finfo-table-map` this gives a more fine
grained understanding of where constructor allocations arise from in a
program.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new flag embeds a lookup table from the address of an info table
to information about that info table.
The main interface for consulting the map is the `lookupIPE` C function
> InfoProvEnt * lookupIPE(StgInfoTable *info)
The `InfoProvEnt` has the following structure:
> typedef struct InfoProv_{
> char * table_name;
> char * closure_desc;
> char * ty_desc;
> char * label;
> char * module;
> char * srcloc;
> } InfoProv;
>
> typedef struct InfoProvEnt_ {
> StgInfoTable * info;
> InfoProv prov;
> struct InfoProvEnt_ *link;
> } InfoProvEnt;
The source positions are approximated in a similar way to the source
positions for DWARF debugging information. They are only approximate but
in our experience provide a good enough hint about where the problem
might be. It is therefore recommended to use this flag in conjunction
with `-g<n>` for more accurate locations.
The lookup table is also emitted into the eventlog when it is available
as it is intended to be used with the `-hi` profiling mode.
Using this flag will significantly increase the size of the resulting
object file but only by a factor of 2-3x in our experience.
|
|
|
|
| |
This reverts commit 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601.
|
| |
|
|
|
|
|
|
|
|
|
| |
The update of the Outputable instance resulted in a slew of
documentation changes within Notes that used the old syntax.
The most important doc changes are to `Note [Demand notation]`
and the user's guide.
Fixes #19016.
|
|
|
|
| |
Thanks @mpickering for finding them!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first change makes the array ones use the proper fixed-size types,
which also means that just like before, they can be used without
explicit conversions with the boxed sized types. (Before, it was Int# /
Word# on both sides, now it is fixed sized on both sides).
For the second change, don't use "extend" or "narrow" in some of the
user-facing primops names for conversions.
- Names like `narrowInt32#` are misleading when `Int` is 32-bits.
- Names like `extendInt64#` are flat-out wrong when `Int is
32-bits.
- `narrow{Int,Word}<N>#` however map a type to itself, and so don't
suffer from this problem. They are left as-is.
These changes are batched together because Alex happend to use the array
ops. We can only use released versions of Alex at this time, sadly, and
I don't want to have to have a release thatwon't work for the final GHC
9.2. So by combining these we get all the changes for Alex done at once.
Bump hackage state in a few places, and also make that workflow slightly
easier for the future.
Bump minimum Alex version
Bump Cabal, array, bytestring, containers, text, and binary submodules
|
|
|
|
|
|
|
| |
Add Data.Type.Ord
Add and update tests
Metric Increase:
MultiLayerModules
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider (`T18610`):
```hs
f :: Bool -> Int
f x = case (x, x) of
(True, True) -> 1
(False, False) -> 2
(True, False) -> 3 -- Warning: Redundant
```
The third clause will be flagged as redundant. Nevertheless, the
programmer might intend to keep the clause in order to avoid bitrot.
After this patch, the programmer can write
```hs
g :: Bool -> Int
g x = case (x, x) of
(True, True) -> 1
(False, False) -> 2
(True, False) | GHC.Exts.considerAccessible -> 3 -- No warning
```
And won't be bothered any longer. See also `Note [considerAccessible]`
and the updated entries in the user's guide.
Fixes #18610 and #19228.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While fixing #18610, I noticed that
```hs
f :: Bool -> Int
f x = case (x, x) of
(True, True) -> 1
(False, False) -> 2
```
was *not* detected as exhaustive. I tracked it down to `equateUSDFM`,
where upon merging equality classes of `x` and `y`, we failed to atually
indirect the *representative* `x'` of the equality class of `x` to the
representative `y'` of `y`.
The fixed code is much more naturally and would I should have written in
the first place. I can confirm that the above example now is detected as
exhaustive. The commit that fixes #18610 comes directly after and it has
`f` above as a regression test, so I saw no need to open a ticket or
commit a separate regression test.
|
|
|
|
|
|
|
| |
If the context is missing it is captured as Nothing, rather than
putting a noLoc in the ParsedSource.
Updates haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #19360 showed up a terrible bug in the occurrence analyser,
in a situation like this
Rec { f = g
; g = ..f...
{-# RULE g .. = ...f... #-} }
Then f was postInlineUnconditionally, but not in the RULE (which
is simplified first), so we had a RULE mentioning a variable that
was not in scope.
This led me to review (again) the subtle loop-breaker stuff in the
occurrence analyser. The actual changes are few, and are largely
simplifications. I did a /lot/ of comment re-organising though.
There was an unexpected amount of fallout.
* Validation failed when compiling the stage2 compiler with profiling
on. That turned to tickle a second latent bug in the same OccAnal
code (at least I think it was always there), which led me to
simplify still further; see Note [inl_fvs] in GHC.Core.Opt.OccurAnal.
* But that in turn let me to some strange behaviour in CSE when ticks
are in the picture, which I duly fixed. See Note [Dealing with ticks]
in GHC.Core.Opt.CSE.
* Then I got an ASSERT failure in CoreToStg, which again seems to be
a latent bug. See Note [Ticks in applications] in GHC.CoreToStg
* I also made one unforced change: I now simplify the RHS of a RULE in
the same way as the RHS of a stable unfolding. This can allow a
trivial binding to disappear sooner than otherwise, and I don't
think it has any downsides. The change is in
GHC.Core.Opt.Simplify.simplRules.
|
|
|
|
| |
This is a first step towards #18738.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #19364 helpfully points out that we do not currently take
advantage of pushing the result type of an application into the
arguments. This makes error messages notably less good.
The fix is rather easy: move the result-type unification step earlier.
It's even a bit more efficient; in the the checking case we now
do one less zonk.
See Note [Unify with expected type before typechecking arguments]
in GHC.Tc.Gen.App
This change generally improves error messages, but it made one worse:
typecheck/should_fail/T16204c. That led me to the realisation that
a good error can be replaced by a less-good one, which provoked
me to change GHC.Tc.Solver.Interact.inertsCanDischarge. It's
explained in the new Note [Combining equalities]
One other refactoring: I discovered that KindEqOrigin didn't need a
Maybe in its type -- a nice simplification.
|
|
|
|
|
|
|
|
|
|
|
| |
Reduce code bloat by replacing a call to `(==)` (which is defined in
terms of `compare`) and to `compare` by a single call to `compare`,
utilising the `Semigroup Ordering` instance.
The compiler was eliminate the code bloat before, so this is a rather
cosmetical improvement.
Fixes #19443.
|
|
|
|
|
|
|
|
|
|
| |
Previously, non-determinism arising from a use of `uniqCompareFS` in
`cmpLit` potentially crept into `CoreMap`, which we expect to behave
deterministically.
So we simply use `lexicalCompareFS` now.
Fixes #19438.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While fixing #17336 we noticed that code like this:
= if | tc == intTyConName -> ...
| tc == int8TyConName -> ...
| tc == int16TyConName -> ...
| tc == int32TyConName -> ...
| tc == int64TyConName -> ...
| tc == wordTyConName -> ...
| tc == word8TyConName -> ...
| tc == word16TyConName -> ...
| tc == word32TyConName -> ...
| tc == word64TyConName -> ...
| tc == naturalTyConName -> ...
was not transformed into a single case expression on the Name's unique
as I would have expected but as a linear search. Bindings for known
names are not simple constructor applications because of their strict
`n_occ :: !OccName` field that needs to allocate a `FastString`: this
field needs to be forced before using the `n_unique` field.
This patch partially reverses ccaf7b66fc79e464b4e26f4ae62cb92ef7ba4b0f by
making `n_occ` lazy and by ensuring that helper functions used to
declare known names are fully inlined. The code above is then
optimised as expected.
Baseline
Test Metric value New value Change
---------------------------------------------------------------------------
ManyAlternatives(normal) ghc/alloc 822810880.0 822104032.0 -0.1%
ManyConstructors(normal) ghc/alloc 4551734924.0 4480621808.0 -1.6%
MultiLayerModules(normal) ghc/alloc 6029108292.0 6016024464.0 -0.2%
Naperian(optasm) ghc/alloc 57396600.0 56826184.0 -1.0%
PmSeriesG(normal) ghc/alloc 55666656.0 54521840.0 -2.1%
PmSeriesS(normal) ghc/alloc 70204344.0 69047328.0 -1.6%
PmSeriesT(normal) ghc/alloc 102273172.0 101070016.0 -1.2%
PmSeriesV(normal) ghc/alloc 69157156.0 68002176.0 -1.7%
T10421(normal) ghc/alloc 129875476.0 128881544.0 -0.8%
T10421a(normal) ghc/alloc 92031552.0 90982800.0 -1.1%
T10547(normal) ghc/alloc 34399800.0 33016760.0 -4.0% GOOD
T10858(normal) ghc/alloc 208316964.0 207318616.0 -0.5%
T11195(normal) ghc/alloc 304100548.0 302797040.0 -0.4%
T11276(normal) ghc/alloc 140586764.0 139469832.0 -0.8%
T11303b(normal) ghc/alloc 52118960.0 51120248.0 -1.9%
T11374(normal) ghc/alloc 241325868.0 240692752.0 -0.3%
T11822(normal) ghc/alloc 150612036.0 149582736.0 -0.7%
T12150(optasm) ghc/alloc 92738452.0 91897224.0 -0.9%
T12227(normal) ghc/alloc 494236296.0 493086728.0 -0.2%
T12234(optasm) ghc/alloc 66786816.0 65966096.0 -1.2%
T12425(optasm) ghc/alloc 112396704.0 111471016.0 -0.8%
T12545(normal) ghc/alloc 1832733768.0 1828021072.0 -0.3%
T12707(normal) ghc/alloc 1054991144.0 1053359696.0 -0.2%
T13035(normal) ghc/alloc 116173180.0 115112072.0 -0.9%
T13056(optasm) ghc/alloc 391749192.0 390687864.0 -0.3%
T13253(normal) ghc/alloc 382785700.0 381550592.0 -0.3%
T13253-spj(normal) ghc/alloc 168806064.0 167987192.0 -0.5%
T13379(normal) ghc/alloc 403890296.0 402447920.0 -0.4%
T13701(normal) ghc/alloc 2542828108.0 2534392736.0 -0.3%
T13719(normal) ghc/alloc 4666717708.0 4659489416.0 -0.2%
T14052(ghci) ghc/alloc 2181268580.0 2175320640.0 -0.3%
T14683(normal) ghc/alloc 3094166824.0 3094524216.0 +0.0%
T14697(normal) ghc/alloc 376323432.0 374024184.0 -0.6%
T15164(normal) ghc/alloc 1896324828.0 1893236528.0 -0.2%
T15630(normal) ghc/alloc 198932800.0 197783656.0 -0.6%
T16190(normal) ghc/alloc 288186840.0 287250024.0 -0.3%
T16577(normal) ghc/alloc 8324100940.0 8321580600.0 -0.0%
T17096(normal) ghc/alloc 318264420.0 316961792.0 -0.4%
T17516(normal) ghc/alloc 1332680768.0 1331635504.0 -0.1%
T17836(normal) ghc/alloc 1296308168.0 1291098504.0 -0.4%
T17836b(normal) ghc/alloc 62008340.0 60745256.0 -2.0%
T17977(normal) ghc/alloc 52954564.0 51890248.0 -2.0%
T17977b(normal) ghc/alloc 47824016.0 46683936.0 -2.4%
T18140(normal) ghc/alloc 117408932.0 116353672.0 -0.9%
T18223(normal) ghc/alloc 5603767896.0 5602037104.0 -0.0%
T18282(normal) ghc/alloc 166456808.0 165396320.0 -0.6%
T18304(normal) ghc/alloc 103694052.0 103513136.0 -0.2%
T18478(normal) ghc/alloc 816819336.0 814459560.0 -0.3%
T18698a(normal) ghc/alloc 438652404.0 437041784.0 -0.4%
T18698b(normal) ghc/alloc 529448324.0 527666608.0 -0.3%
T18923(normal) ghc/alloc 78360824.0 77315560.0 -1.3%
T1969(normal) ghc/alloc 854223208.0 851303488.0 -0.3%
T3064(normal) ghc/alloc 200655808.0 199368872.0 -0.6%
T3294(normal) ghc/alloc 1791121792.0 1790033888.0 -0.1%
T4801(normal) ghc/alloc 343749816.0 341760680.0 -0.6%
T5030(normal) ghc/alloc 377520872.0 376492360.0 -0.3%
T5321FD(normal) ghc/alloc 312680408.0 311618536.0 -0.3%
T5321Fun(normal) ghc/alloc 355635656.0 354536264.0 -0.3%
T5631(normal) ghc/alloc 629667068.0 629562192.0 -0.0%
T5642(normal) ghc/alloc 540913864.0 539569952.0 -0.2%
T5837(normal) ghc/alloc 43183652.0 42177928.0 -2.3%
T6048(optasm) ghc/alloc 96395616.0 95397032.0 -1.0%
T783(normal) ghc/alloc 427778908.0 426307760.0 -0.3%
T9020(optasm) ghc/alloc 279523960.0 277010040.0 -0.9%
T9233(normal) ghc/alloc 966717488.0 964594096.0 -0.2%
T9630(normal) ghc/alloc 1585228636.0 1581428672.0 -0.2%
T9675(optasm) ghc/alloc 594817892.0 591703040.0 -0.5%
T9872a(normal) ghc/alloc 2216955420.0 2215648024.0 -0.1%
T9872b(normal) ghc/alloc 2747814924.0 2746515472.0 -0.0%
T9872c(normal) ghc/alloc 2271878772.0 2270554344.0 -0.1%
T9872d(normal) ghc/alloc 623661168.0 621434064.0 -0.4%
T9961(normal) ghc/alloc 409059124.0 406811120.0 -0.5%
WWRec(normal) ghc/alloc 940563924.0 938008112.0 -0.3%
hie002(normal) ghc/alloc 9801941116.0 9787675736.0 -0.1%
parsing001(normal) ghc/alloc 494756632.0 493828512.0 -0.2%
Metric Decrease:
T10547
T13035
T12425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For years we have lived in a supposedly sweet spot that gave case
binders the CPR property, unconditionally. Which is an optimistic hack
that is now described in `Historical Note [Optimistic case binder CPR]`.
In #19232 the concern was raised that this might do more harm than good
and that might be better off simply by taking the CPR property of the
scrutinee for the CPR type of the case binder. And indeed that's what we
do now.
Since `Note [CPR in a DataAlt case alternative]` is now only about field
binders, I renamed and garbage collected it into
`Note [Optimistic field binder CPR]`.
NoFib approves:
```
NoFib Results
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
anna +0.1% +0.1%
nucleic2 -1.2% -0.6%
sched 0.0% +0.9%
transform -0.0% -0.1%
--------------------------------------------------------------------------------
Min -1.2% -0.6%
Max +0.1% +0.9%
Geometric Mean -0.0% +0.0%
```
Fixes #19232.
|
|
|
|
| |
Found with ghc-debug on the ManyConstructors test
|
|
|
|
| |
pprUserSpan, isZeroWidthSpan, pprLocated, combineRealSrcSpans
|
|
|
|
|
| |
The previous code using TyCoMapper could promote the same metavar twice.
Use a set instead.
|
|
|
|
|
|
|
|
| |
As noted in #19102, we would previously ended up reboxing the tuple
result of `split`'s worker and then immediately take apart the boxed
tuple to again unpack it into an unboxed result.
Fixes #19102.
|
|
|
|
|
| |
Following the example of Note [The one-shot state monad trick].
c.f. #18202.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following the example of Note [The one-shot state monad trick].
c.f. #18202.
Metric Decrease:
T17836
T3064
T5321FD
T9872a
T9872b
T9872c
T9872d
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
When desugaring large overloaded literals we now avoid
computing the `Rational` value. Instead prefering to
store the significant and exponent as given where
reasonable and possible.
See Note [FractionalLit representation] for details.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using -fdicts-strict we generate references to absentError while
compiling ghc-prim. However we always load ghc-prim before base so this
caused linker errors.
We simply solve this by moving absentError into ghc-prim. This does mean
it's now a panic instead of an exception which can no longer be caught.
But given that it should only be thrown if there is a compiler error
that seems acceptable, and in fact we already do this for
absentSumFieldError which has similar constraints.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'Stream' is implemented in the "yoneda" style for efficiency. By
representing a stream in this manner 'fmap' and '>>=' operations are
accumulated in the function parameters before being applied once when
the stream is destroyed. In the old implementation each usage of 'mapM'
and '>>=' would traverse the entire stream in order to apply the
substitution at the leaves. It is well-known for free monads that this
representation can improve performance, and the test results
demonstrate this for GHC as well.
The operation mapAccumL is not used in the compiler and can't be
implemented efficiently because it requires destroying and rebuilding
the stream.
I removed one use of mapAccumL_ which has similar problems but the other
use was difficult to remove. In the future it may be worth exploring
whether the 'Stream' encoding could be modified further to capture the
mapAccumL pattern, and likewise defer the passing of accumulation
parameter until the stream is finally consumed.
The >>= operation for 'Stream' was a hot-spot in the ticky profile for
the "ManyConstructors" test which called the 'cg' function many times in
"StgToCmm.hs"
Metric Decrease:
ManyConstructors
|
|
|
|
|
|
| |
Fixes #18966. Adds a new warning -Wambiguous-fields for uses of field selectors
or record updates that will be rejected in the future, when the DuplicateRecordFields
extension is simplified per https://github.com/ghc-proposals/ghc-proposals/pull/366.
|
|
|
|
|
| |
It makes the external package state independent of the home unit which
is needed to make several home units share the EPS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the change the error did not show details of involved module:
```
haddock: panic! (the 'impossible' happened)
(GHC version 8.10.3:
ModOrigin: hidden module redefined
```
After the change modile details are shown:
```
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 9.1.20210206:
ModOrigin: package both exposed/hidden
x: exposed package
y: reexport by ghc-boot-9.1
```
Fixes #19330
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
| |
This was observed to build up thunks which were forced by using
a `-hi` profile and T3294 as a test.
|
|
|
|
|
| |
This value is eventually forced so don't build up thunks.
Observed with T3294 and -hi profile.
|
|
|
|
|
|
| |
I observed this accumulating in the T3294 test only to be eventually
forced (by a -hi profile). As it is only word big, forcing it saves quite a bit of
allocation.
|
| |
|
| |
|