| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enhances OccurAnal perf by using a dedicated WithUsageDetails
datatype instead of a tuple (similarly to what has been done in
demand-analysis) with strict fields.
OccEnv is also passed strictly with more strict fields as it improves
results even more.
T9198 flukes isn't reproducible locally (cf
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5667#note_364358)
Metric Decrease:
ManyConstructors
T10421
T12150
T12425
T12707
T13056
T13253
T13253-spj
T15164
T16577
T18282
T18698a
T18698b
T1969
T4801
T5642
T9020
T9233
T9630
T9675
T9961
WWRec
T12227
T13035
T18304
T6048
T12234
T783
T20049
Metric Increase:
T9198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue was the renderer for x86 addressing modes assumes native size
registers, but we were passing in a possibly-smaller index in
conjunction with a native-sized base pointer.
The easist thing to do is just extend the register first.
I also changed the other NGC backends implementing jump tables
accordingly. On one hand, I think PowerPC and Sparc don't have the small
sub-registers anyways so there is less to worry about. On the other
hand, to the extent that's true the zero extension can become a no-op.
I should give credit where it's due: @hsyl20 really did all the work for
me in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_355874,
but I was daft and missed the "Oops" and so ended up spending a silly
amount of time putting it all back together myself.
The unregisterised backend change is a bit different, because here we
are translating the actual case not a jump table, and the fix is to
handle right-sized literals not addressing modes. But it makes sense to
include here too because it's the same change in the subsequent commit
that exposes both bugs.
|
|
|
|
| |
Fixes #19373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit refactors the SuggestExtension type constructor of the
GhcHint to be more powerful and flexible. In particular, we can now
embed extra user information (essentially "sugar") to help clarifying
the suggestion. This makes the following possible:
Suggested fix: Perhaps you intended to use GADTs
or a similar language extension to enable syntax: data T where
We can still give to IDEs and tools a `LangExt.Extension` they can use,
but in the pretty-printed message we can tell the user a bit more on why
such extension is needed.
On top of that, we now have the ability to express conjuctions and
disjunctons, for those cases where GHC suggests to enable "X or Y" and
for the cases where we need "X and Y".
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GHC.Prim module is quite special as there is no interface file,
therefore it doesn't appear in ms_textual_imports, but the ghc-prim
package does appear in the direct package dependencies. This confused
the recompilation checking which couldn't find any modules from ghc-prim
and concluded that the package was no longer a dependency.
The fix is to keep track of whether GHC.Prim is imported separately in
the relevant places.
Fixes #20084
|
|
|
|
|
|
|
|
|
| |
This is small step towards #19877. We want to make the Loader/Linker
interface more abstract to be easily reused (i.e. don't pass it
DynFlags) but the system linker uses TmpFs which required a DynFlags
value to get its temp directory. We explicitly pass the temp directory
now. Similarly TmpFs was consulting the DynFlags to decide whether to
clean or: this is now done by the caller in the driver code.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #20125 showed that the Simplifier could sometimes duplicate a
constructor binding. CSE would often eliminate it later, but doing it
in the first place was utterly wrong.
See Note [Do not duplicate constructor applications] in Simplify.hs
I also added a short-cut to Simplify.simplNonRecX for the case
when the RHS is trivial. I don't think this will change anything,
just make the compiler run a tiny bit faster.
|
|
|
|
|
|
|
|
|
|
| |
This commit renames the `RecordPuns` type constructor inside
`GHC.LanguageExtensions.Type.hs` to `NamedFieldPuns`.
The rationale is that the `RecordPuns` language extension was deprecated
a long time ago, but it was still present in the AST, introducing an
annoying mismatch between what GHC suggested (i.e. "use NamedFieldPuns")
and what that translated into in terms of Haskell types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code assumed properties of the CoreToStg translation,
namely that a core let expression which be translated to a single
non-recursive top-level STG binding. This assumption was false, as
evidenced by #20060.
The consequence of this was the need to modify the call sites of
`myCoreToStgExpr`, the main one being in hscCompileCoreExpr', which
the meant we had to use byteCodeGen instead of stgExprToBCOs to convert
the returned value to bytecode.
I removed the `stgExprToBCOs` function as it is no longer
used in the compiler.
There is still some partiallity with this patch (the lookup in
hscCompileCoreExpr') but this should be more robust that before.
Fixes #20060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch, provoked by regressions in the text package
(#19557), improves sharing of join points. This also fixes
the terrible behaviour in #20049.
See Note [Duplicating join points] in GHC.Core.Opt.Simplify.
* In the StrictArg case of mkDupableContWithDmds, don't
use Plan A for data constructors
* In postInlineUnconditionally, don't inline JoinIds
Avoids inlining join $j x = Just x
in case blah of
A -> $j x1
B -> $j x2
C -> $j x3
* In mkDupableStrictBind and mkDupableStrictAlt, create
join points (much) more often: exprIsTrivial rather than
exprIsDupable. This may be much, but we'll see.
Metric Decrease:
T12545
T13253-spj
T13719
T18140
T18282
T18304
T18698a
T18698b
Metric Increase:
T16577
T18923
T9961
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Word64#/Int64# are only used on 32-bit architectures. Before this patch,
operations on these types were directly using the FFI. Now we use real
primops that are then lowered into ccalls.
The advantage of doing this is that we can now perform constant folding on
Word64#/Int64# (#19024).
Most of this work was done by John Ericson in !3658. However this patch
doesn't go as far as e.g. changing Word64 to always be using Word64#.
Noticeable performance improvements
T9203(normal) run/alloc 89870808.0 66662456.0 -25.8% GOOD
haddock.Cabal(normal) run/alloc 14215777340.8 12780374172.0 -10.1% GOOD
haddock.base(normal) run/alloc 15420020877.6 13643834480.0 -11.5% GOOD
Metric Decrease:
T9203
haddock.Cabal
haddock.base
|
|
|
|
|
|
|
|
| |
Add a constant folding rule allowing the subsumption of an application
if the same argument is applied twice, e.g.
(v .&. 0xFF) .&. 0xFF ~~> v .&. 0xFF
(v .|. 0xFF) .|. 0xFF ~~> v .|. 0xFF
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Spurious warnings were previously emitted if an import came from a
reexport due to how -Wunused-packages were implemented. Removing the
dependency would cause compilation to fail.
The fix is to reimplement the warning a bit more directly, by searching
for which package each import comes from using the normal module finding
functions rather than consulting the EPS. This has the advantage that
the check could be performed at any time after downsweep rather than
also relying on a populated EPS.
Fixes #19518 and #19777
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds proper hints to most diagnostic types in the
`GHC.Parser.Errors.Types` module. By "proper" we mean that previous to
this commit the hints were bundled together with the diagnostic message,
whereas now we moved most of them as proper `[GhcHint]` in the
implementation of `diagnosticHints`.
More specifically, this is the list of constructors which now has
proper hints:
* PsErrIllegalBangPattern
* PsWarnOperatorWhitespaceExtConflict
* PsErrLambdaCase
* PsErrIllegalPatSynExport
* PsWarnOperatorWhitespace
* PsErrMultiWayIf
* PsErrIllegalQualifiedDo
* PsErrNumUnderscores
* PsErrLinearFunction
* PsErrIllegalTraditionalRecordSyntax
* PsErrIllegalExplicitNamespace
* PsErrOverloadedRecordUpdateNotEnabled
* PsErrIllegalDataTypeContext
* PsErrSemiColonsInCondExpr
* PsErrSemiColonsInCondCmd
* PsWarnStarIsType
* PsWarnImportPreQualified
* PsErrImportPostQualified
* PsErrEmptyDoubleQuotes
* PsErrIllegalRoleName
* PsWarnStarBinder
For some reason, this patch increases the peak_megabyte_allocated of
the T11545 test to 90 (from a baseline of 80) but that particular test
doesn't emit any parsing diagnostic or hint and the metric increase
happens only for the `aarch64-linux-deb10`.
Metric Increase:
T11545
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- fixes #18149 and #14765
dsWhenNoErrs now returns "runtimeError @ty" when disallowed
representation polymorphism is detected, where ty is the type of the
result CoreExpr. "ty" is passed as an additional argument to
dsWhenNoErrs, and is used only in the case of such an error.
The calls to dsWhenNoErrs must now compute the type of the
CoreExpr they are trying to build, so that an error of the right type
can be used in case of a representation polymorphism failure.
|
|
|
|
|
|
|
|
| |
getProgName was used to append the name of the program (e.g. "ghc") to
printed error messages in the Show instance of GhcException. It doesn't
belong here as GHCi and GHC API users may want to override this behavior
by setting a different error handler. So we now call it in the
defaultErrorHandler instead.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This commit adds the TcRnShadowedName to the TcRnMessage type and it
uses it in GHC.Rename.Utils.
|
|
|
|
|
|
|
|
|
|
|
| |
This commit renames the `getErrorMessages` and
`getMessages` function in the parser code to `getPsErrorMessages` and
`getPsMessages`, to avoid import conflicts, as we have already
`getErrorMessages` and `getMessages` defined in `GHC.Types.Error`.
Fixes #19920.
Update haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch converts the runPipeline function to be implemented in terms
of a free monad rather than the previous CompPipeline.
The advantages of this are three-fold:
1. Different parts of the pipeline can return different results, the
limits of runPipeline were being pushed already by !5555, this opens up
futher fine-grainedism of the pipeline.
2. The same mechanism can be extended to build-plan at the module level
so the whole build plan can be expressed in terms of one computation
which can then be treated uniformly.
3. The pipeline monad can now be interpreted in different ways, for
example, you may want to interpret the `TPhase` action into the monad
for your own build system (such as shake). That bit will probably
require a bit more work, but this is a step in the right directin.
There are a few more modules containing useful functions for interacting
with the pipelines.
* GHC.Driver.Pipeline: Functions for building pipelines at a high-level
* GHC.Driver.Pipeline.Execute: Functions for providing the default
interpretation of TPhase, in terms of normal IO.
* GHC.Driver.Pipeline.Phases: The home for TPhase, the typed phase data
type which dictates what the phases are.
* GHC.Driver.Pipeline.Monad: Definitions to do with the TPipelineClass
and MonadUse class.
Hooks consumers may notice the type of the `phaseHook` has got
slightly more restrictive, you can now no longer control the
continuation of the pipeline by returning the next phase to execute but
only override individual phases. If this is a problem then please open
an issue and we will work out a solution.
-------------------------
Metric Decrease:
T4029
-------------------------
|
|
|
|
|
| |
When arguments are 8 *or 16* bits wide, then truncate before/after
and use the 32bit operation.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #20070, we noticed that `findRhsArity` copes badly with shadowing.
A simple function like `g_123 x_123 = x_123`, where the labmda binder shadows,
already regressed badly.
Indeed, the whole `arityType` function wasn't thinking about shadowing *at all*.
I rectified that and established the invariant that `ae_join` and `am_sigs`
should always be disjoint. That entails deleting bindings from `ae_join`
whenever we add something to `am_sigs` and vice versa, which would otherwise be
a bug in the making.
That *should* fix (but I don't want to close it) #20070.
|
|
|
|
| |
fixes #19628
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I discovered that GHC.Core.Unify.bindTv was getting arity 2,
rather than 3, in one of my builds. In HEAD it does get the right
arity, but only because CallArity (just) manages to spot it. In my
situation it (just) failed to discover this.
Best to make it robust, which this patch does. See
Note [INLINE pragmas and (>>)] in GHC.Utils.Monad.
There a bunch of other modules that probably should have the same
treatment:
GHC.CmmToAsm.Reg.Linear.State
GHC.Tc.Solver.Monad
GHC.Tc.Solver.Rewrite
GHC.Utils.Monad.State.Lazy
GHC.Utils.Monad.State.Strict
but doing so is not part of this patch
|
| |
|
|
|
|
| |
clang's cpp injects spaces prior to #!/.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use DiagOpts for diagnostic options instead of directly querying
DynFlags (#17957).
Surprising performance improvements on CI:
T4801(normal) ghc/alloc 313236344.0 306515216.0 -2.1% GOOD
T9961(normal) ghc/alloc 384502736.0 380584384.0 -1.0% GOOD
ManyAlternatives(normal) ghc/alloc 797356128.0 786644928.0 -1.3%
ManyConstructors(normal) ghc/alloc 4389732432.0 4317740880.0 -1.6%
T783(normal) ghc/alloc 408142680.0 402812176.0 -1.3%
Metric Decrease:
T4801
T9961
T783
ManyAlternatives
ManyConstructors
Bump haddock submodule
|
| |
|
| |
|
|
|
|
| |
Fixes #14380, #19997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19050, we identified several ways in which we could make more illegal
states irrepresentable. This patch introduces a few representation changes
around `Demand` and `Card` with a better and earlier-failing API exported
through pattern synonyms. Specifically,
1. The old enum definition of `Card` led to severely bloated code of operations
on it. I switched to a bit vector representation; much nicer overall IMO.
See Note [Bit vector representation for Card].
Most of the gripes with the old representation were related to where which kind
of `Card` was allowed and the fact that it doesn't make sense for an absent or
bottoming demand to carry a `SubDemand` that describes an evaluation context
that is never realised.
2. So I refactored the `Demand` representation so that it has two new data
constructors for `AbsDmd` and `BotDmd`. The old `(:*)` data constructor
becomes a pattern synonym which expands absent demands as needed, so that
it still forms a complete match and a versatile builder. The new `Demand`
data constructor now carries a `CardNonAbs` and only occurs in a very limited
number of internal call sites.
3. Wherever a full-blown `Card` might end up in a `CardNonAbs` field (like that
of `D` or `Call`), I assert the consistency. When the smart builder of `(:*)`
is called with an absent `Card`, I assert that the `SubDemand` is the same
that we would expand to in the matcher.
4. `Poly` now takes a `CardNonOnce` and encodes the previously noticed invariant
that we never produce `Poly C_11` or `Poly C_01`. I made sure that we never
construct a `Poly` with `C_11` or `C_01`.
Fixes #19050.
We lose a tiny bit of anal perf overall, probably because the new `Demand`
definition can't be unboxed. The biggest loser is WWRec, where allocations go
from 16MB to 26MB in DmdAnal, making up for a total increase of (merely) 1.6%.
It's all within acceptance thresholds.
There are even two ghc/alloc metric decreases. T11545 decreases by *67%*!
Metric Decrease:
T11545
T18304
|
|
|
|
|
|
| |
This is a follow-up to #19992, which fixes the type and strictness signature
for `fork#`. The `forkOn#` primop also needs analogous changes, which this
patch accomplishes.
|
|
|
|
|
|
|
|
|
|
|
| |
This commit tries to untangle the zoo of diagnostic-related functions
in `Tc.Utils.Monad` so that we can have the interfaces mentions only
`TcRnMessage`s while we push the creation of these messages upstream.
It also ports TcRnMessage diagnostics to use the new API, in particular
this commit switch to use TcRnMessage in the external interfaces
of the diagnostic functions, and port the old SDoc to be wrapped
into TcRnUnknownMessage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d1f59540e8b7be96b55ab4b286539a70bc75416c.
This commit breaks the build of unordered-containers
```
[3 of 9] Compiling Data.HashMap.Internal.Array ( Data/HashMap/Internal/Array.hs, dist/build/Data/HashMap/Internal/Array.o, dist/build/Data/HashMap/Internal/Array.dyn_o )
*** Parser [Data.HashMap.Internal.Array]:
Parser [Data.HashMap.Internal.Array]: alloc=21043544 time=13.621
*** Renamer/typechecker [Data.HashMap.Internal.Array]:
Renamer/typechecker [Data.HashMap.Internal.Array]: alloc=151218672 time=187.083
*** Desugar [Data.HashMap.Internal.Array]:
ghc: panic! (the 'impossible' happened)
GHC version 9.3.20210625:
expectJust splitFunTy
CallStack (from HasCallStack):
error, called at compiler/GHC/Data/Maybe.hs:68:27 in ghc:GHC.Data.Maybe
expectJust, called at compiler/GHC/Core/Type.hs:1247:14 in ghc:GHC.Core.Type
```
Revert containers submodule update
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part of fixing #19766 required the emission of `LitRubbish` as absent filler in
places where we used `absentError` before. In WWRec we have the situation that
such bindings occur in the argument to functions. With `LitRubbish` we inlined
those functions, because
1. The absent binding was regarded as ConLike. So I fixed `exprIsHNFLike` to
respond `False` to `LitRubbish`.
2. The other source of inlining was that after inlining such an absent
binding, `LitRubbish` itself was regarded `ValueArg` by `interestingArg`,
leading to more inlining. It now responds `TrivArg` to `LitRubbish`.
Fixes #20035.
There's one slight 1.6% ghc/alloc regression left in T15164 that is due to an
additional specialisation `$s$cget`. I've no idea why that happens; the Core
output before is identical and has the call site that we specialise for.
Metric Decrease:
WWRec
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5814#note_355144,
Simon noted that `mkWWstr` and `mkWWcpr` could generate fewer let bindings and
be implemented less indirectly by returning the rebuilt expressions directly, e.g. instead of
```
f :: (Int, Int) -> Int
f (x, y) = x+y
==>
f :: (Int, Int) -> Int
f p = case p of (x, y) ->
case x of I# x' ->
case y of I# y' ->
case $wf x' y' of r' ->
let r = I# r' -- immediately returned
in r
f :: Int# -> Int# -> Int#
$wf x' y' = let x = I# x' in -- only used in p
let y = I# y' in -- only used in p
let p = (x, y) in -- only used in the App below
case (\(x,y) -> x+y) p of I# r' ->
r'
```
we know generate
```
f :: (Int, Int) -> Int
f p = case p of (x, y) ->
case x of I# x' ->
case y of I# y' ->
case $wf x' y' of r' ->
I# r' -- 1 fewer let
f :: Int# -> Int# -> Int#
$wf x' y' = case (\(x,y) -> x+y) (I# x, I# y) of I# r' -> -- 3 fewer lets
r'
```
Which is much nicer and makes it easier to comprehend the output of
worker-wrapper pre-Simplification as well as puts less strain on the Simplifier.
I had to drop support for #18983, but we found that it's broken anyway.
Simon is working on a patch that provides a bit more justification.
|