| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is follow-up to https://ghc.haskell.org/trac/ghc/ticket/10773
Reviewers: austin, goldfire, bgamari, RyanGlScott
Reviewed By: RyanGlScott
Subscribers: RyanGlScott, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3816
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit da4687f63ffe5a6162e3d7856aa53de048dd0f42.
It's not entirely trivial to clean up the dead code this patch
introduced. In particular, when we see
```
case raiseIO# m s of
s' -> e
```
we want to know that `e` is dead. For scrutinees that are properly
bottom (which we don't want to consider `raiseIO# m s` to be, this
is handled by rewriting `bot` to `case bot of {}`. But if we do
that for `raiseIO#`, we end up with
```
case raiseIO# m s of {}
```
which looks a lot like bottom and could confuse demand analysis.
I think we need to wait with this change until we have a more
complete story.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3413
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They were `expect_broken` without any output. Add the actual
output and remove the `expect_broken`.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3306
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The script I used is included as testsuite/driver/kill_extra_files.py,
though at this point it is for mostly historical interest.
Some of the tests in libraries/hpc relied on extra_files.py, so this
commit includes an update to that submodule.
One test in libraries/process also relies on extra_files.py, but we
cannot update that submodule so easily, so for now we special-case it
in the test driver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disabling worker/wrapper for NOINLINE things can cause unnecessary
reboxing of values. Consider
{-# NOINLINE f #-}
f :: Int -> a
f x = error (show x)
g :: Bool -> Bool -> Int -> Int
g True True p = f p
g False True p = p + 1
g b False p = g b True p
the strictness analysis will discover f and g are strict, but because f
has no wrapper, the worker for g will rebox p. So we get
$wg x y p# =
let p = I# p# in -- Yikes! Reboxing!
case x of
False ->
case y of
False -> $wg False True p#
True -> +# p# 1#
True ->
case y of
False -> $wg True True p#
True -> case f p of { }
g x y p = case p of (I# p#) -> $wg x y p#
Now, in this case the reboxing will float into the True branch, an so
the allocation will only happen on the error path. But it won't float
inwards if there are multiple branches that call (f p), so the reboxing
will happen on every call of g. Disaster.
Solution: do worker/wrapper even on NOINLINE things; but move the
NOINLINE pragma to the worker.
Test Plan: make test TEST="13143"
Reviewers: simonpj, bgamari, dfeuer, austin
Reviewed By: simonpj, bgamari
Subscribers: dfeuer, thomie
Differential Revision: https://phabricator.haskell.org/D3046
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is a refinement of the original commit (which
was reverted):
commit 6b976eb89fe72827f226506d16d3721ba4e28bab
Date: Fri Jan 13 08:56:53 2017 +0000
Record evaluated-ness on workers and wrappers
In Trac #13027, comment:20, I noticed that wrappers created after
demand analysis weren't recording the evaluated-ness of strict
constructor arguments. In the ticket that led to a (debatable)
Lint error but in general the more we know about evaluated-ness
the better we can optimise.
This commit adds that info
* both in the worker (on args)
* and in the wrapper (on CPR result patterns).
See Note [Record evaluated-ness in worker/wrapper] in WwLib
On the way I defined Id.setCaseBndrEvald, and used it to shorten
the code in a few other places
Then I added test T13077a to test the CPR aspect of this patch,
but I found that Lint failed!
Reason: simpleOptExpr was discarding evaluated-ness info on
lambda binders because zapFragileIdInfo was discarding an
Unfolding of (OtherCon _). But actually that's a robust
unfolding; there is no need to discard it. To fix this:
* zapFragileIdInfo only zaps fragile unfoldings
* Replace isClosedUnfolding with isFragileUnfolding (the latter
is just the negation of the former, but the nomenclature is
more consistent). Better documentation too
Note [Fragile unfoldings]
* And Simplify.simplLamBndr can now look at isFragileUnfolding
to decide whether to use the longer route of simplUnfolding.
For some reason perf/compiler/T9233 improves in compile-time
allocation by 10%. Hooray
Nofib: essentially no change:
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
cacheprof +0.0% -0.3% +0.9% +0.4% +0.0%
--------------------------------------------------------------------------------
Min +0.0% -0.3% -2.4% -2.4% +0.0%
Max +0.0% +0.0% +9.8% +11.4% +2.4%
Geometric Mean +0.0% -0.0% +1.1% +1.0% +0.0%
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `clean_cmd` and `extra_clean` setup functions don't do anything.
Remove them from .T files.
Created using https://github.com/thomie/refactor-ghc-testsuite. This
diff is a test for the .T-file parser/processor/pretty-printer in that
repository.
find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
Tests containing inline comments or multiline strings are not modified.
Preparation for #12223.
Test Plan: Harbormaster
Reviewers: austin, hvr, simonmar, mpickering, bgamari
Reviewed By: mpickering
Subscribers: mpickering
Differential Revision: https://phabricator.haskell.org/D3000
GHC Trac Issues: #12223
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [ABot branches: use max] in CoreArity.
I stumbled on this when investigating something else, and
opened Trac #13031 to track it.
It's very hard to tickle the bug, which is why it has lurked so long,
but the test
stranal/should_compile/T13031
does so
Oddly, the testsuite framework doesn't actually run the test; I have
no idea why.
|
|
|
|
|
|
|
| |
Any variable with useful information (strict or used-once) will not be
included in lazy_fv (according to splitFVs). If we now also remove them
from the strictness signatures, their uses are not recorded anywhere –
and then probably considered absent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this fixes #12368.
It also refactors dmdFix a bit, removes some redundancies (such as
passing around an strictness signature right next to an id, when that id
is guaranteed to have been annotated with that strictness signature).
Note that when fixed-point iteration does not terminate, we
conservatively delete their strictness signatures (set them to nopSig).
But this loses the information on how its strict free variables are
used!
Lazily used variables already escape via lazy_fvs. We ensure that in the
case of an aborted fixed-point iteration, also the strict variables are
put there (with a conservative demand of topDmd).
Differential Revision: https://phabricator.haskell.org/D2392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the implementation match the description in the paper more
closely: There, a let binding that is not a function has first its body
analised, and then the binding’s RHS. This way, the demand on the bound
variable by the body can be fed into the RHS, yielding more precise
results.
Performance measurements do unfortunately not show significant
improvements or regessions.
Differential Revision: https://phabricator.haskell.org/D2395
|
|
|
|
|
| |
By making it believe that some deeply nested value is absent when it
really isn't. See #12368.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change help message so it doesn't specify -auto-all.
Make old profiling flags deprecated as they are no longer
documented.
Update Makefile and documentation accordingly.
Update release notes for ghc 8.2
Test Plan:
./verify; `ghc --help` shouldn't specify the -auto-all
flag. Furthermore `ghc -fprof -auto-all` should emit a warning
Reviewed By: thomie, austin
Differential Revision: https://phabricator.haskell.org/D2257
GHC Trac Issues: #12084
Update submodule nofib
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in order to have precise used-once information in the exported
strictness signatures, as well as precise used-once information on
thunks. This avoids the bad effects of #11731.
The subsequent worker-wrapper pass is responsible for removing the
demand environment part of the strictness signature. It does not run
after the final demand analyzer pass, so remove this also in CoreTidy.
The subsequent worker-wrapper pass is also responsible for removing
used-once-information from the demands and strictness signatures, as
these might not be preserved by the simplifier. This is _not_ done by
CoreTidy, because we _do_ want this information, as produced by the last
round of the demand analyzer, to be available to the code generator.
Differential Revision: https://phabricator.haskell.org/D2073
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as suggested in ticket:11770#comment:1. This code was buggy
(#11770), and the occurrence analyzer does the same job anyways.
This also elaborates the notes in the occurrence analyzer accordingly.
Previously, the worker/wrapper code would go through lengths to transfer
the oneShot annotations from the original function to both the worker
and the wrapper. We now simply transfer the demand on the worker, and
let the subsequent occurrence analyzer push this onto the lambda
binders.
This also requires the occurrence analyzer to do this more reliably.
Previously, it would not hand out OneShot annotatoins to things that
would not `certainly_inline` (and it might not have mattered, as the
Demand Analysis might have handed out the annotations). Now we hand out
one-shot annotations unconditionally.
Differential Revision: https://phabricator.haskell.org/D2085
|
|
|
|
|
|
|
| |
This reverts commit 28fe0eea4d161b707f67aae26fddaa2e60d8a901 due to
various regressions. I’m not sure why my local
./validate --slow
run did not catch this, though.
|
|
|
|
|
|
|
|
|
| |
as suggested in ticket:11770#comment:1. This code was buggy (#11770),
and the occurrence analyzer does the same job anyways.
This also elaborates the notes in the occurrence analyzer accordingly.
Differential Revision: https://phabricator.haskell.org/D2070
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This turns `Any` into a standard wired-in type family defined in
`GHC.Types`, instead its current incarnation as a magical creature
provided by the `GHC.Prim`. Also kill `AnyK`.
See #10886.
Test Plan: Validate
Reviewers: simonpj, goldfire, austin, hvr
Reviewed By: simonpj
Subscribers: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D2049
GHC Trac Issues: #10886
|
|
|
|
|
| |
and use normalise_errmsg_fun to check the core output in all.T, instead
relying on code in the Makefile.
|
|
|
|
| |
too verbose, and usualy preceded by Str= anyways.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `MonadFail`is available, this patch makes `MonadFail` a superclass
of `Quasi`, and `Q` an instance of `MonadFail`.
NB: Since f16ddcee0c64a92ab911a7841a8cf64e3ac671fd, we need to be able
to compile `template-haskell` with stage0 compilers that don't provide
a `MonadFail` class yet. Once we reach GHC 8.3 development we can drop
the CPP conditionals again.
Addresses #11661
Reviewed By: bgamari, goldfire
Differential Revision: https://phabricator.haskell.org/D1982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Replace "Sigs" with "Signatures" in WarningFlag data constructors.
- Replace "PatSyn" with "PatternSynonym" in WarningFlag data
constructors.
- Deprecate "missing-local-sigs" in favor of "missing-local-signatures".
- Deprecate "missing-exported-sigs" in favor of
"missing-exported-signatures".
- Deprecate "missing-pat-syn-signatures" in favor of
"missing-pattern-synonym-signatures".
- Replace "ddump-strsigs" with "ddump-str-signatures"
These complete the tasks that were explicitly mentioned in #11583
Test Plan:
Executed `ghc --show-options` and verified that the flags were changed
as expected.
Reviewers: svenpanne, austin, bgamari
Reviewed By: austin, bgamari
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D1939
GHC Trac Issues: #11583
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to make this work I needed to shuffle around typechecking a bit
such that `TyCon` and friends are available during compilation of
GHC.Types. I also did a bit of refactoring of `TcTypeable`.
Test Plan: Validate
Reviewers: simonpj, austin
Subscribers: simonpj, thomie
Differential Revision: https://phabricator.haskell.org/D1906
GHC Trac Issues: #11120
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Trac #11222, and #10712 note, the strictness analyser
needs to be rather careful about exceptions. Previously
it treated them as identical to divergence, but that
won't quite do.
See Note [Exceptions and strictness] in Demand, which
explains the deal.
Getting more strictness in 'catch' and friends is a
very good thing. Here is the nofib summary, keeping
only the big ones.
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
fasta -0.1% -6.9% -3.0% -3.0% +0.0%
hpg -0.1% -2.0% -6.2% -6.2% +0.0%
maillist -0.1% -0.3% 0.08 0.09 +1.2%
reverse-complem -0.1% -10.9% -6.0% -5.9% +0.0%
sphere -0.1% -4.3% 0.08 0.08 +0.0%
x2n1 -0.1% -0.0% 0.00 0.00 +0.0%
--------------------------------------------------------------------------------
Min -0.2% -10.9% -17.4% -17.3% +0.0%
Max -0.0% +0.0% +4.3% +4.4% +1.2%
Geometric Mean -0.1% -0.3% -2.9% -3.0% +0.0%
On the way I did quite a bit of refactoring in Demand.hs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 547c597112954353cef7157cb0a389bc4f6303eb modifies the
pretty-printer to render names from a set of core packages (`base`,
`ghc-prim`, `template-haskell`) as unqualified. The idea here was that
many of these names typically are not in scope but are well-known by the
user and therefore qualification merely introduces noise.
This, however, is a very large hammer and potentially breaks any
consumer who relies on parsing GHC output (hence #11208). This commit
partially reverts this change, now only printing `Constraint` (which
appears quite often in errors) as unqualified.
Fixes #11208.
Updates tests in `array` submodule.
Test Plan: validate
Reviewers: hvr, thomie, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1619
GHC Trac Issues: #11208
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the ideas originally put forward in
"System FC with Explicit Kind Equality" (ICFP'13).
There are several noteworthy changes with this patch:
* We now have casts in types. These change the kind
of a type. See new constructor `CastTy`.
* All types and all constructors can be promoted.
This includes GADT constructors. GADT pattern matches
take place in type family equations. In Core,
types can now be applied to coercions via the
`CoercionTy` constructor.
* Coercions can now be heterogeneous, relating types
of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
proves both that `t1` and `t2` are the same and also that
`k1` and `k2` are the same.
* The `Coercion` type has been significantly enhanced.
The documentation in `docs/core-spec/core-spec.pdf` reflects
the new reality.
* The type of `*` is now `*`. No more `BOX`.
* Users can write explicit kind variables in their code,
anywhere they can write type variables. For backward compatibility,
automatic inference of kind-variable binding is still permitted.
* The new extension `TypeInType` turns on the new user-facing
features.
* Type families and synonyms are now promoted to kinds. This causes
trouble with parsing `*`, leading to the somewhat awkward new
`HsAppsTy` constructor for `HsType`. This is dispatched with in
the renamer, where the kind `*` can be told apart from a
type-level multiplication operator. Without `-XTypeInType` the
old behavior persists. With `-XTypeInType`, you need to import
`Data.Kind` to get `*`, also known as `Type`.
* The kind-checking algorithms in TcHsType have been significantly
rewritten to allow for enhanced kinds.
* The new features are still quite experimental and may be in flux.
* TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
* TODO: Update user manual.
Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
Updates Haddock submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The idea here is that this gives a more detailed stack trace in two
cases:
1. With `-prof` and `-fprof-auto`
2. In GHCi (see #11047)
Example, with an error inserted in nofib/shootout/binary-trees:
```
$ ./Main 3
Main: z
CallStack (from ImplicitParams):
error, called at Main.hs:67:29 in main:Main
CallStack (from -prof):
Main.check' (Main.hs:(67,1)-(68,82))
Main.check (Main.hs:63:1-21)
Main.stretch (Main.hs:32:35-57)
Main.main.c (Main.hs:32:9-57)
Main.main (Main.hs:(27,1)-(43,42))
Main.CAF (<entire-module>)
```
This doesn't quite obsolete +RTS -xc, which also attempts to display
more information in the case when the error is in a CAF, but I'm
exploring other solutions to that.
Includes submodule updates.
Test Plan: validate
Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Foreign calls may not be strict for lifted arguments. Fixes Trac #11076.
Test Plan: ./validate
Reviewers: simonpj, bgamari, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1464
GHC Trac Issues: #11076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second attempt at merging D757.
This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.
However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.
See particularly
* Note [Grand plan for Typeable] in TcTypeable (which is a new module)
* Note [The overall promotion story] in DataCon (clarifies existing
stuff)
The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:
* We need to have enough data types around to *define* a TyCon
* Many of these types are wired-in
Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.
Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969
* T1969: GHC allocates 19% more
* T4801: GHC allocates 13% more
* T5321FD: GHC allocates 13% more
* T9675: GHC allocates 11% more
* T783: GHC allocates 11% more
* T5642: GHC allocates 10% more
I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.
Remaining to do
~~~~~~~~~~~~~~~
* I think that "TyCon" and "Module" are over-generic names to use for
the runtime type representations used in GHC.Typeable. Better might
be
"TrTyCon" and "TrModule". But I have not yet done this
* Add more info the the "TyCon" e.g. source location where it was
defined
* Use the new "Module" type to help with Trac Trac #10068
* It would be possible to generate TyConRepName (ie Typeable
instances) selectively rather than all the time. We'd need to persist
the information in interface files. Lacking a motivating reason I
have
not done this, but it would not be difficult.
Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular
* In TyCon, a type *family* (whether type or data) is repesented by a
FamilyTyCon
* a algebraic data type (including data/newtype instances) is
represented by AlgTyCon This wasn't true before; a data family
was represented as an AlgTyCon. There are some corresponding
changes in IfaceSyn.
* Also get rid of the (unhelpfully named) tyConParent.
* In TyCon define 'Promoted', isomorphic to Maybe, used when things are
optionally promoted; and use it elsewhere in GHC.
* Cleanup handling of knownKeyNames
* Each TyCon, including promoted TyCons, contains its TyConRepName, if
it has one. This is, in effect, the name of its Typeable instance.
Updates haddock submodule
Test Plan: Let Harbormaster validate
Reviewers: austin, hvr, goldfire
Subscribers: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D1404
GHC Trac Issues: #9858
|
|
|
|
|
|
|
|
| |
This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c.
This merge was botched
Also reverts haddock submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.
However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.
See particularly
* Note [Grand plan for Typeable] in TcTypeable (which is a new module)
* Note [The overall promotion story] in DataCon (clarifies existing stuff)
The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:
* We need to have enough data types around to *define* a TyCon
* Many of these types are wired-in
Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.
Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969
* T3294: GHC allocates 110% more (filed #11030 to track this)
* T1969: GHC allocates 30% more
* T4801: GHC allocates 14% more
* T5321FD: GHC allocates 13% more
* T783: GHC allocates 12% more
* T9675: GHC allocates 12% more
* T5642: GHC allocates 10% more
* T9961: GHC allocates 6% more
* T9203: Program allocates 54% less
I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.
Remaining to do
~~~~~~~~~~~~~~~
* I think that "TyCon" and "Module" are over-generic names to use for
the runtime type representations used in GHC.Typeable. Better might be
"TrTyCon" and "TrModule". But I have not yet done this
* Add more info the the "TyCon" e.g. source location where it was
defined
* Use the new "Module" type to help with Trac Trac #10068
* It would be possible to generate TyConRepName (ie Typeable
instances) selectively rather than all the time. We'd need to persist
the information in interface files. Lacking a motivating reason I have
not done this, but it would not be difficult.
Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular
* In TyCon, a type *family* (whether type or data) is repesented by a
FamilyTyCon
* a algebraic data type (including data/newtype instances) is
represented by AlgTyCon This wasn't true before; a data family
was represented as an AlgTyCon. There are some corresponding
changes in IfaceSyn.
* Also get rid of the (unhelpfully named) tyConParent.
* In TyCon define 'Promoted', isomorphic to Maybe, used when things are
optionally promoted; and use it elsewhere in GHC.
* Cleanup handling of knownKeyNames
* Each TyCon, including promoted TyCons, contains its TyConRepName, if
it has one. This is, in effect, the name of its Typeable instance.
Requires update of the haddock submodule.
Differential Revision: https://phabricator.haskell.org/D757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default top-level exception handler now uses the `Show` instance for
`ErrorCall` when printing exceptions, so it will actually print the out-of-band
data (e.g. `CallStack`s) in compiled binaries, instead of just printing the
error message.
This also updates the hpc submodule to fix the test output.
Reviewed By: austin, thomie
Differential Revision: https://phabricator.haskell.org/D1217
|
|
|
|
|
| |
These two testsuite files were correct in my build
tree but not in my source tree; apologies.
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit
commit 0696fc6d4de28cb589f6c751b8491911a5baf774
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Fri Jun 26 11:40:01 2015 +0100
I made an error in the is_var_scrut tests in extendEnvForProdAlt.
This patch fixes it, thereby fixing Trac #10694.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When working on Trac #10482 I noticed that we could give constructor
arguments the CPR property if they are use strictly.
This is documented carefully in
Note [CPR in a product case alternative]
and also
Note [Initial CPR for strict binders]
There are a bunch of intersting examples in
Note [CPR examples]
which I have added to the test suite as T10482a.
I also added a test for #10482 itself.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It's kind of buggy, c.f. #10182, and isn't motivated by any
real world programs, so we're going to get rid of it (despite
it being handy for GHC test cases.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D862
|
|
|
|
|
| |
as Simons recent commit 9b9fc4c732baab126b057b4031bebcbd67d6e348 fixed
this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10218 reports a subtle bug that turned out to be:
- CSE invalidated the usage information computed
by earlier demand analysis, by increasing sharing
- that made a single-entry thunk into a multi-entry thunk
- and with -feager-blackholing, that led to <<loop>>
The patch fixes it by making the CSE pass zap usage information for
let-bound identifiers. It can be restored by -flate-dmd-anal.
(But making -flate-dmd-anal the default needs some careful work;
see Trac #7782.)
|
| |
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
| |
|