| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This very small patch switches on sm_inline even in the InitialPhase
(aka "gentle" phase). There is no reason not to... and the results
are astonishing.
I think the peformance of GHC itself improves by about 5%; and some
programs get much smaller, quicker. Result: across the board
irmprovements in
compile time performance. Here are the changes in perf/compiler;
the numbers are decreases in compiler bytes-allocated:
3% T5837
7% parsing001
9% T12234
35% T9020
9% T3064
13% T9961
20% T13056
5% T9872d
5% T9872c
5% T9872b
7% T9872a
5% T783
35% T12227
20% T1969
Plus in perf/should_run
5% lazy-bs-alloc
It wasn't as easy as it sounds: I did a raft of preparatory work in
earlier patches. But it's great!
Reviewers: austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Make `liftA2` a method of `Applicative`.
* Add explicit `liftA2` definitions to instances in `base`.
* Add explicit invocations in `base`.
Reviewers: ekmett, bgamari, RyanGlScott, austin, hvr
Reviewed By: RyanGlScott
Subscribers: ekmett, RyanGlScott, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #12425 and #12234 showed up a major and long-standing
bug in the occurrence analyser, whereby it could generate
explonentially large program!
There's a lot of commentary on #12425; and it's all described
in Note [Loop breakers, node scoring, and stability]
I did quite a lot of refactoring to make the code comprehensibe
again (its structure had bit-rotted rather), so the patch
looks bigger than it really is.
Hurrah!
I did a nofib run to check that I hadn't inadertently ruined
anything:
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
fluid -0.3% -1.5% 0.01 0.01 +0.0%
parser -0.9% +0.6% 0.04 0.04 +0.0%
prolog -0.1% +1.2% 0.00 0.00 +0.0%
--------------------------------------------------------------------------------
Min -0.9% -1.5% -8.6% -8.7% +0.0%
Max +0.1% +1.2% +7.7% +7.8% +2.4%
Geometric Mean -0.2% -0.0% -0.2% -0.3% +0.0%
I checked what happened in 'prolog'. It seems that we have a
recursive data structure something like this
f :: [blah]
f x = build (\cn. ...g... )
g :: [blah2]
g y = ....(foldr k z (f y))....
If we inline 'f' into 'g' we get better fusion than the other
way round, but we don't have any way to spot that at the moment.
(I wonder if we could do worker/wrapper for functions returning
a 'build'?) It was happening before by a fluke.
Anyway I decided to accept this; it's relatively rare I think.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch began as a modest refactoring of HsType and friends, to
clarify and tidy up exactly where quantification takes place in types.
Although initially driven by making the implementation of wildcards more
tidy (and fixing a number of bugs), I gradually got drawn into a pretty
big process, which I've been doing on and off for quite a long time.
There is one compiler performance regression as a result of all
this, in perf/compiler/T3064. I still need to look into that.
* The principal driving change is described in Note [HsType binders]
in HsType. Well worth reading!
* Those data type changes drive almost everything else. In particular
we now statically know where
(a) implicit quantification only (LHsSigType),
e.g. in instance declaratios and SPECIALISE signatures
(b) implicit quantification and wildcards (LHsSigWcType)
can appear, e.g. in function type signatures
* As part of this change, HsForAllTy is (a) simplified (no wildcards)
and (b) split into HsForAllTy and HsQualTy. The two contructors
appear when and only when the correponding user-level construct
appears. Again see Note [HsType binders].
HsExplicitFlag disappears altogether.
* Other simplifications
- ExprWithTySig no longer needs an ExprWithTySigOut variant
- TypeSig no longer needs a PostRn name [name] field
for wildcards
- PatSynSig records a LHsSigType rather than the decomposed
pieces
- The mysterious 'GenericSig' is now 'ClassOpSig'
* Renamed LHsTyVarBndrs to LHsQTyVars
* There are some uninteresting knock-on changes in Haddock,
because of the HsSyn changes
I also did a bunch of loosely-related changes:
* We already had type synonyms CoercionN/CoercionR for nominal and
representational coercions. I've added similar treatment for
TcCoercionN/TcCoercionR
mkWpCastN/mkWpCastN
All just type synonyms but jolly useful.
* I record-ised ForeignImport and ForeignExport
* I improved the (poor) fix to Trac #10896, by making
TcTyClsDecls.checkValidTyCl recover from errors, but adding a
harmless, abstract TyCon to the envt if so.
* I did some significant refactoring in RnEnv.lookupSubBndrOcc,
for reasons that I have (embarrassingly) now totally forgotten.
It had to do with something to do with import and export
Updates haddock submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it so the result of computing SCC's depends on the order
the nodes were passed to it, but not on the order on the user provided
key type.
The key type is usually `Unique` which is known to be nondeterministic.
Test Plan:
`text` and `aeson` become deterministic after this
./validate
Compare compile time for `text`:
```
$ cabal get text && cd text* && cabal sandbox init && cabal install
--dependencies-only && time cabal build
real 0m59.459s
user 0m57.862s
sys 0m1.185s
$ cabal clean && time cabal build
real 1m0.037s
user 0m58.350s
sys 0m1.199s
$ cabal clean && time cabal build
real 0m57.634s
user 0m56.118s
sys 0m1.202s
$ cabal get text && cd text* && cabal sandbox init && cabal install
--dependencies-only && time cabal build
real 0m59.867s
user 0m58.176s
sys 0m1.188s
$ cabal clean && time cabal build
real 1m0.157s
user 0m58.622s
sys 0m1.177s
$ cabal clean && time cabal build
real 1m0.950s
user 0m59.397s
sys 0m1.083s
```
Reviewers: ezyang, simonmar, austin, bgamari
Reviewed By: simonmar, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1268
GHC Trac Issues: #4012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we have an orphan rule in our database, don't apply it
unless the defining module is transitively imported by the
module we are processing. We do this by defining a new RuleEnv
data type which includes both the RuleBase as well as the set
of visible orphan modules, and threading this through the
relevant environments (CoreReader, RuleCheckEnv and ScEnv).
This is analogous to the instances fix we applied in #2182
4c834fdddf4d44d12039da4d6a2c63a660975b95, but done for RULES.
An important knock-on effect is that we can remove some buggy
code in LoadInterface which tried to avoid loading interfaces
that were loaded by plugins (which sometimes caused instances
and rules to NEVER become visible).
One note about tests: I renamed the old plugins07 test to T10420
and replaced plugins07 with a test to ensure that a plugin
import did not cause new rules to be loaded in.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, goldfire
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D950
GHC Trac Issues: #10420
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea was promted by Trac #9939, but it was Christmas, so I did
some recreational programming that went much further.
The idea is to warn when a constraint in a user-supplied context is
redundant. Everything is described in detail in
Note [Tracking redundant constraints]
in TcSimplify.
Main changes:
* The new ic_status field in an implication, of type ImplicStatus.
It replaces ic_insol, and includes information about redundant
constraints.
* New function TcSimplify.setImplicationStatus sets the ic_status.
* TcSigInfo has sig_report_redundant field to say whenther a
redundant constraint should be reported; and similarly
the FunSigCtxt constructor of UserTypeCtxt
* EvBinds has a field eb_is_given, to record whether it is a given
or wanted binding. Some consequential chagnes to creating an evidence
binding (so that we record whether it is given or wanted).
* AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds;
see Note [Typechecking plan for instance declarations] in
TcInstDcls
* Some significant changes to the type checking of instance
declarations; Note [Typechecking plan for instance declarations]
in TcInstDcls.
* I found that TcErrors.relevantBindings was failing to zonk the
origin of the constraint it was looking at, and hence failing to
find some relevant bindings. Easy to fix, and orthogonal to
everything else, but hard to disentangle.
Some minor refactorig:
* TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds
* TcClassDcl and TcInstDcls now have their own code for typechecking
a method body, rather than sharing a single function. The shared
function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code
and the differences were growing confusing.
* Add new function TcRnMonad.pushLevelAndCaptureConstraints, and
use it
* Add new function Bag.catBagMaybes, and use it in TcSimplify
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of silent superclass parameters was to solve the
awkward problem of superclass dictinaries being bound to bottom.
See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls
Although the silent-superclass idea worked,
* It had non-local consequences, and had effects even in Haddock,
where we had to discard silent parameters before displaying
instance declarations
* It had unexpected peformance costs, shown up by Trac #3064 and its
test case. In monad-transformer code, when constructing a Monad
dictionary you had to pass an Applicative dictionary; and to
construct that you neede a Functor dictionary. Yet these extra
dictionaries were often never used. (All this got much worse when
we added Applicative as a superclass of Monad.) Test T3064
compiled *far* faster after silent superclasses were eliminated.
* It introduced new bugs. For example SilentParametersOverlapping,
T5051, and T7862, all failed to compile because of instance overlap
directly because of the silent-superclass trick.
So this patch takes a new approach, which I worked out with Dimitrios
in the closing hours before Christmas. It is described in detail
in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls.
Seems to work great!
Quite a bit of knock-on effect
* The main implementation work is in tcSuperClasses in TcInstDcls
Everything else is fall-out
* IdInfo.DFunId no longer needs its n-silent argument
* Ditto IDFunId in IfaceSyn
* Hence interface file format changes
* Now that DFunIds do not have silent superclass parameters, printing
out instance declarations is simpler. There is tiny knock-on effect
in Haddock, so that submodule is updated
* I realised that when computing the "size of a dictionary type"
in TcValidity.sizePred, we should be rather conservative about
type functions, which can arbitrarily increase the size of a type.
Hence the new datatype TypeSize, which has a TSBig constructor for
"arbitrarily big".
* instDFunType moves from TcSMonad to Inst
* Interestingly, CmmNode and CmmExpr both now need a non-silent
(Ord r) in a couple of instance declarations. These were previously
silent but must now be explicit.
* Quite a bit of wibbling in error messages
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generally clean up things relating to Applicative and Monad in `GHC.Base`
and `Control.Applicative` to make `Applicative` feel like a bit more of a
first-class citizen rather than just playing second fiddle to `Monad`. Use
`coerce` and GND to improve performance and clarity.
Change the default definition of `(*>)` to use `(<$)`, in case the
`Functor` instance optimizes that.
Moreover, some manually written instances are made into compiler-derived
instances.
Finally, this also adds a few AMP-related laws to the `Applicative` docstring.
NOTE: These changes result in a 13% decrease in allocation for T9020
Reviewed By: ekmett, hvr
Differential Revision: https://phabricator.haskell.org/D432
|
|
|
|
|
|
|
|
|
|
| |
Akio found an avoidable cause of non-determinisim: The names of RULES
generated by Specialise had uniques in them:
"SPEC $cshowsPrec_a2QX @ [GHC.Types.Char]" [ALWAYS] forall ...
By using showSDocForUser instead of showSDocDump when building the rule
name, this is avoided:
"SPEC $cshowsPrec @ [Char]" [ALWAYS] forall ...
See #4012, comments 61ff.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.
As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: Austin Seipp <austin@well-typed.com>
Test Plan: Build things, they might not explode horribly.
Reviewers: hvr, simonmar
Subscribers: simonmar
Differential Revision: https://phabricator.haskell.org/D13
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two main refactorings here
1. Move the uf_arity field
out of CoreUnfolding
into UnfWhen
It's a lot tidier there. If I've got this right, no behaviour
should change.
2. Define specUnfolding and use it in DsBinds and Specialise
a) commons-up some shared code
b) makes sure that Specialise correctly specialises DFun
unfoldings (which it didn't before)
The two got put together because both ended up interacting in the
specialiser.
They cause zero difference to nofib.
|
|
|
|
|
|
|
|
| |
Previously we always printed qualified names, but that makes a lot of debug or
warning output very verbose. So now we only print qualified names with -dppr-debug.
Civilised output (from pukka error messages, with the environment available) is
unaffected
|
|
|