| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
| |
One more step towards the new design of EPA.
|
| |
|
|
|
|
| |
Fix ghc/ghc#21739
Squash fix ghc/ghc#21739
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main fix for #21667 is the new call to tcInstTypeBnders
in tcHsPartialSigType. It was really a simple omission before.
I also moved the decision about whether we need to apply the
Monomorphism Restriction, from `decideGeneralisationPlan` to
`tcPolyInfer`. That removes a flag from the InferGen constructor,
which is good.
But more importantly, it allows the new function,
checkMonomorphismRestriction
called from `tcPolyInfer`, to "see" the `Types` involved rather than
the `HsTypes`. And that in turn matters because we invoke the MR for
partial signatures if none of the partial signatures in the group have
any overloading context; and we can't answer that question for HsTypes.
See Note [Partial type signatures and the monomorphism restriction]
in GHC.Tc.Gen.Bind.
This latter is really a pre-existing bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to the fix to #20836 in CorePrep, we now track the set of enclosing
recursive binders in the SimplEnv and SimpleOptEnv.
See Note [Eta reduction in recursive RHSs] for details.
I also updated Note [Arity robustness] with the insights Simon and I had in a
call discussing the issue.
Fixes #21652.
Unfortunately, we get a 5% ghc/alloc regression in T16577. That is due to
additional eta reduction in GHC.Read.choose1 and the resulting ANF-isation
of a large list literal at the top-level that didn't happen before (presumably
because it was too interesting to float to the top-level). There's not much we
can do about that.
Metric Increase:
T16577
|
| |
|
|
|
|
|
|
|
|
|
| |
In #20836 we have optimised a terminating program into an endless loop,
because we speculated the self-recursive call of a recursive DFun.
Now we track the set of enclosing recursive binders in CorePrep to prevent
speculation of such self-recursive calls.
See the updates to Note [Speculative evaluation] for details.
Fixes #20836.
|
| |
|
|
|
|
|
|
| |
The recursive DFun in the reproducer for #20836 also triggered a bug in CprAnal
that is observable in a debug build. The CPR signature of a recursive DFunId
was never updated and hence the optimistic arity 0 bottom signature triggered a
mismatch with the arity 1 of the binding in WorkWrap. We never miscompiled any
code because WW doesn't exploit bottom CPR signatures.
|
| |
|
|
|
|
|
|
| |
The code generated for IntMulMayOflo was previously wrong as it
depended upon the overflow flag, which the AArch64 MUL instruction does
not set. Fix this.
Fixes #21624.
|
| |
|
|
| |
Previously this produced invalid assembly containing a redundant comma.
|
| |
|
|
| |
These will be needed to fix #21624.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Despite this code having been present in the core-to-bytecode
implementation, I have observed it in the wild starting with 9.2,
causing enormous slowdown in certain situations.
My test case produces the following profiles:
Before:
```
total time = 559.77 secs (559766 ticks @ 1000 us, 1 processor)
total alloc = 513,985,665,640 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc ticks bytes
elem_by Data.OldList libraries/base/Data/OldList.hs:429:1-7 67.6 92.9 378282 477447404296
eqInt GHC.Classes libraries/ghc-prim/GHC/Classes.hs:275:8-14 12.4 0.0 69333 32
$c>>= GHC.Data.IOEnv <no location info> 6.9 0.6 38475 3020371232
```
After:
```
total time = 89.83 secs (89833 ticks @ 1000 us, 1 processor)
total alloc = 39,365,306,360 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc ticks bytes
$c>>= GHC.Data.IOEnv <no location info> 43.6 7.7 39156 3020403424
doCase GHC.StgToByteCode compiler/GHC/StgToByteCode.hs:(805,1)-(1054,53) 2.5 7.4 2246 2920777088
```
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The call sites in `Driver.Main` are duplicative, but this is good,
because the next step is to remove `InteractiveContext` from `Core.Lint`
into `Core.Lint.Interactive`.
Also further clean up `Core.Lint` to use a better configuration record
than the one we initially added.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors hasFixedRuntimeRep_remainingValArgs, renaming it
to tcRemainingValArgs. The logic is moved to rebuildHsApps, which
ensures consistent behaviour across tcApp and quickLookArg1/tcEValArg.
This patch also refactors the treatment of stupid theta for data
constructors, changing the place we drop stupid theta arguments
from dsConLike to mkDataConRep (now the datacon wrapper drops these
arguments).
We decided not to implement PHASE 2 of the FixedRuntimeRep plan for
these remaining ValArgs. Future directions are outlined on the wiki:
https://gitlab.haskell.org/ghc/ghc/-/wikis/Remaining-ValArgs
Fixes #21544 and #21650
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to process the rhs of non-recursive bindings and their body
using the same env. If we had something like
let x = ... x ...
this caused trouble because the two xs refer to different binders
but we would substitute both for a new binder x2 causing out of scope
errors.
We now simply use two different envs for the rhs and body in cse_bind.
It's all explained in the Note [Separate envs for let rhs and body]
Fixes #21685
|
| |
|
|
| |
Co-Authored-By: Andre Marianiello <andremarianiello@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
In the Specialiser, we missed one more call to
bringFloatedDictsIntoScope (see #21391).
This omission led to #21689. The problem is that the call
to `rewriteClassOps` needs to have in scope any dictionaries
floated out of the arguments we have just specialised.
Easy fix.
|
| |
|
|
|
|
| |
Replaces uses of `TcRnUnknownMessage` with proper diagnostics
constructors in `GHC.Tc.Gen.Match`, `GHC.Tc.Gen.Pat`, and
`GHC.Tc.Gen.Sig`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes #20312
It deprecates "TypeInType" extension
according to the following proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0083-no-type-in-type.rst
It has been already implemented.
The migration strategy:
1. Disable TypeInType
2. Enable both DataKinds and PolyKinds extensions
Metric Decrease:
T16875
|
| |
|
|
|
|
| |
Finishes what !7467 (closed) started.
Progress towards #17957
|
| |
|
|
|
| |
We have the length already, so we might as well use that rather than
O(n) recomputing it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As proposed in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7508#note_432877 and
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7508#note_434676,
`GHC.HsToCore.Ticks` is about ticks, breakpoints are separate and
backend-specific (only for the bytecode interpreter), and mix entry
writing is just for HPC.
With this split we separate out those interpreter- and HPC-specific
its, and keep the main `GHC.HsToCore.Ticks` agnostic.
Also, instead of passing the reversed list and count around, we use
`SizedSeq` which abstracts over the algorithm. This is much nicer to
avoid noise and prevents bugs.
(The bugs are not just hypothetical! I missed up the reverses on an
earlier draft of this commit.)
|
| |
|
|
|
|
| |
The old name made it confusing why disabling HPC didn't disable the
entire pass. The name makes it clear --- there are other reasons to add
ticks in addition.
|
| |
|
|
|
|
| |
No need to inline traversing a maybe for `mkModBreaks`. And better to
make each function do one thing and let the caller deside when than
scatter the decision making and make the caller seem more imperative.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a follow-up to !7247 (closed) making the inclusion of compact unwinding
sections the default.
Also a slight refactoring/simplification of the flag handling to add
-fno-compact-unwind.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit redefines the structure of Splices in the AST.
We get rid of `HsSplice` which used to represent typed and untyped
splices, quasi quotes, and the result of splicing either an expression,
a type or a pattern.
Instead we have `HsUntypedSplice` which models an untyped splice or a
quasi quoter, which works in practice just like untyped splices.
The `HsExpr` constructor `HsSpliceE` which used to be constructed with
an `HsSplice` is split into `HsTypedSplice` and `HsUntypedSplice`. The
former is directly constructed with an `HsExpr` and the latter now takes
an `HsUntypedSplice`.
Both `HsType` and `Pat` constructors `HsSpliceTy` and `SplicePat` now
take an `HsUntypedSplice` instead of a `HsSplice` (remember only
/untyped splices/ can be spliced as types or patterns).
The result of splicing an expression, type, or pattern is now
comfortably stored in the extension fields `XSpliceTy`, `XSplicePat`,
`XUntypedSplice` as, respectively, `HsUntypedSpliceResult (HsType
GhcRn)`, `HsUntypedSpliceResult (Pat GhcRn)`, and `HsUntypedSpliceResult
(HsExpr GhcRn)`
Overall the TTG extension points are now better used to
make invalid states unrepresentable and model the progression between
stages better.
See Note [Lifecycle of an untyped splice, and PendingRnSplice]
and Note [Lifecycle of an typed splice, and PendingTcSplice] for more
details.
Updates haddock submodule
Fixes #21263
-------------------------
Metric Decrease:
hard_hole_fits
-------------------------
|
| |
|
|
|
| |
UntypedSpliceFlavour was only used in the client-specific `GHC.Hs.Expr`
but was defined in the client-independent L.H.S.Expr.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
too hard
Progress towards #17957
Because of `CoreM`, I did not move the `DynFlags` and `HscEnv` to other
modules as thoroughly as I usually do. This does mean that risk of
`DynFlags` "creeping back in" is higher than it usually is.
After we do the same process to the other Core passes, and then figure
out what we want to do about `CoreM`, we can finish the job started
here.
That is a good deal more work, however, so it certainly makes sense to
land this now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes two bugs which were adding dependencies on alex/happy when
building from a source dist.
* When we try to pass `--with-alex` and `--with-happy` to cabal when
configuring but the builders are not set. This is fixed by making them
optional.
* When we configure, cabal requires alex/happy because of the
build-tool-depends fields. These are now made optional with a cabal
flag (build-tool-depends) for compiler/hpc-bin/genprimopcode.
Fixes #21627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large collection of changes all relating to eta
reduction, originally triggered by #18993, but there followed
a long saga.
Specifics:
* Move state-hack stuff from GHC.Types.Id (where it never belonged)
to GHC.Core.Opt.Arity (which seems much more appropriate).
* Add a crucial mkCast in the Cast case of
GHC.Core.Opt.Arity.eta_expand; helps with T18223
* Add clarifying notes about eta-reducing to PAPs.
See Note [Do not eta reduce PAPs]
* I moved tryEtaReduce from GHC.Core.Utils to GHC.Core.Opt.Arity,
where it properly belongs. See Note [Eta reduce PAPs]
* In GHC.Core.Opt.Simplify.Utils.tryEtaExpandRhs, pull out the code for
when eta-expansion is wanted, to make wantEtaExpansion, and all that
same function in GHC.Core.Opt.Simplify.simplStableUnfolding. It was
previously inconsistent, but it's doing the same thing.
* I did a substantial refactor of ArityType; see Note [ArityType].
This allowed me to do away with the somewhat mysterious takeOneShots;
more generally it allows arityType to describe the function, leaving
its clients to decide how to use that information.
I made ArityType abstract, so that clients have to use functions
to access it.
* Make GHC.Core.Opt.Simplify.Utils.rebuildLam (was stupidly called
mkLam before) aware of the floats that the simplifier builds up, so
that it can still do eta-reduction even if there are some floats.
(Previously that would not happen.) That means passing the floats
to rebuildLam, and an extra check when eta-reducting (etaFloatOk).
* In GHC.Core.Opt.Simplify.Utils.tryEtaExpandRhs, make use of call-info
in the idDemandInfo of the binder, as well as the CallArity info. The
occurrence analyser did this but we were failing to take advantage here.
In the end I moved the heavy lifting to GHC.Core.Opt.Arity.findRhsArity;
see Note [Combining arityType with demand info], and functions
idDemandOneShots and combineWithDemandOneShots.
(These changes partly drove my refactoring of ArityType.)
* In GHC.Core.Opt.Arity.findRhsArity
* I'm now taking account of the demand on the binder to give
extra one-shot info. E.g. if the fn is always called with two
args, we can give better one-shot info on the binders
than if we just look at the RHS.
* Don't do any fixpointing in the non-recursive
case -- simple short cut.
* Trim arity inside the loop. See Note [Trim arity inside the loop]
* Make SimpleOpt respect the eta-reduction flag
(Some associated refactoring here.)
* I made the CallCtxt which the Simplifier uses distinguish between
recursive and non-recursive right-hand sides.
data CallCtxt = ... | RhsCtxt RecFlag | ...
It affects only one thing:
- We call an RHS context interesting only if it is non-recursive
see Note [RHS of lets] in GHC.Core.Unfold
* Remove eta-reduction in GHC.CoreToStg.Prep, a welcome simplification.
See Note [No eta reduction needed in rhsToBody] in GHC.CoreToStg.Prep.
Other incidental changes
* Fix a fairly long-standing outright bug in the ApplyToVal case of
GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
tail of 'dmds' in the recursive call, which meant the demands were All
Wrong. I have no idea why this has not caused problems before now.
* Delete dead function GHC.Core.Opt.Simplify.Utils.contIsRhsOrArg
Metrics: compile_time/bytes allocated
Test Metric Baseline New value Change
---------------------------------------------------------------------------------------
MultiLayerModulesTH_OneShot(normal) ghc/alloc 2,743,297,692 2,619,762,992 -4.5% GOOD
T18223(normal) ghc/alloc 1,103,161,360 972,415,992 -11.9% GOOD
T3064(normal) ghc/alloc 201,222,500 184,085,360 -8.5% GOOD
T8095(normal) ghc/alloc 3,216,292,528 3,254,416,960 +1.2%
T9630(normal) ghc/alloc 1,514,131,032 1,557,719,312 +2.9% BAD
parsing001(normal) ghc/alloc 530,409,812 525,077,696 -1.0%
geo. mean -0.1%
Nofib:
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
banner +0.0% +0.4% -8.9% -8.7% 0.0%
exact-reals +0.0% -7.4% -36.3% -37.4% 0.0%
fannkuch-redux +0.0% -0.1% -1.0% -1.0% 0.0%
fft2 -0.1% -0.2% -17.8% -19.2% 0.0%
fluid +0.0% -1.3% -2.1% -2.1% 0.0%
gg -0.0% +2.2% -0.2% -0.1% 0.0%
spectral-norm +0.1% -0.2% 0.0% 0.0% 0.0%
tak +0.0% -0.3% -9.8% -9.8% 0.0%
x2n1 +0.0% -0.2% -3.2% -3.2% 0.0%
--------------------------------------------------------------------------------
Min -3.5% -7.4% -58.7% -59.9% 0.0%
Max +0.1% +2.2% +32.9% +32.9% 0.0%
Geometric Mean -0.0% -0.1% -14.2% -14.8% -0.0%
Metric Decrease:
MultiLayerModulesTH_OneShot
T18223
T3064
T15185
T14766
Metric Increase:
T9630
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch concerns #20155, part (1)
The general idea is that since primops have curried bindings
(currently in PrimOpWrappers.hs) we don't need to eta-expand
them. But we /do/ need to eta-expand the levity-polymorphic ones,
because they /don't/ have bindings.
This patch makes a start in that direction, by identifying the
levity-polymophic primops in the PrimOpId IdDetails constructor.
For the moment, I'm still eta-expanding all primops (by saying
that hasNoBinding returns True for all primops), because of the
bug reported in #20155. But I hope that before long we can
tidy that up too, and remove the TEMPORARILY stuff in hasNoBinding.
|
| | |
|
| |
|
|
|
| |
This avoids a fixpoint iteration for the common case of
non-recursive bindings.
|
| |
|
|
|
| |
Sometimes there are very large casts, and coercionRKind
can be slow.
|
| |
|
|
|
|
|
| |
We want to be able to eta-reduce
\x y. ((f x) |> co) y
by pushing 'co' inwards. A very small change accommodates this
See Note [Eta reduction with casted function]
|
| |
|
|
|
|
| |
This is preliminary work for JavaScript support. It's better to put the
code handling the desugaring of Prim, C and JavaScript declarations into
separate modules.
|
| |
|
|
|
|
|
| |
It was previously disabled because of:
- a confusion about "SRT inlining" (see removed comment in this commit)
- a linker bug (overflow) in the handling of ARM64_RELOC_SUBTRACTOR
relocation: fixed by a previous commit.
|
| |
|
|
|
|
|
|
|
| |
- reordered the 3 SRT implementation cases from the most general to the
most specific one:
USE_SRT_POINTER -> USE_SRT_OFFSET -> USE_INLINE_SRT_FIELD
- added requirements for each
- found and documented a confusion about "SRT inlining" not supported
with MachO. (It is fixed in the following commit)
|
| |
|
|
| |
it is still re-exported from GHC.Exts
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit acb188e0 introduced a regression in the computation of free
variables in mdo statements, as the logic in
GHC.Rename.Expr.segmentRecStmts was slightly different depending on
whether the recursive do block corresponded to an mdo statement or
a rec statment.
This patch restores the previous computation for mdo blocks.
Fixes #21654
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This moves handling of the magic 'withDict' function from the desugarer
to the typechecker. Details in Note [withDict].
I've extracted a part of T16646Fail to a separate file T16646Fail2,
because the new error in 'reify' hides the errors from 'f' and 'g'.
WithDict now works with casts, this fixes #21328.
Part of #19915
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function breakTyVarCycle_maybe has been installed
in a dark corner of GHC to catch some gremlins (a.k.a.
occurs-check failures) who lurk
there. But it previously only caught gremlins of the
form (a ~ ... F a ...), where some of our intrepid users
have spawned gremlins of the form (G a ~ ... F (G a) ...).
This commit improves breakTyVarCycle_maybe (and renames
it to breakTyEqCycle_maybe) to catch the new gremlins.
Happily, the change is remarkably small.
The gory details are in Note [Type equality cycles].
Test cases: typecheck/should_compile/{T21515,T21473}.
|
| | |
|
