| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
has a key invariant `UniqFM` does not. For example, `fmap` over
`UniqSet` will generally produce nonsense.
* Upgrade `UniqSet` from a type synonym to a newtype.
* Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`.
* Use cached unique in `tyConsOfType` by replacing
`unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.
Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari
Reviewed By: niteria
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3146
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This major patch implements Join Points, as described in
https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have
to read that page, and especially the paper it links to, to
understand what's going on; but it is very cool.
It's Luke Maurer's work, but done in close collaboration with Simon PJ.
This Phab is a squash-merge of wip/join-points branch of
http://github.com/lukemaurer/ghc. There are many, many interdependent
changes.
Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin
Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie
Differential Revision: https://phabricator.haskell.org/D2853
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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%
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 6b976eb89fe72827f226506d16d3721ba4e28bab.
Ben, Ryan and I decided to revert this for now due to T12234 failing
and causing all harbormaster builds to fail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
While fixing Trac #12444 I found an occasion on which we applied
worker/wrapper to a DFunId. This is bad: it destroys the magic
DFunUnfolding.
This patch is a minor refactoring that stops this corner case
happening, and tidies up the code a bit too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add prettyprinter tests, which take a file, parse it, pretty print it,
re-parse the pretty printed version and then compare the original and
new ASTs (ignoring locations)
Updates haddock submodule to match the AST changes.
There are three issues outstanding
1. Extra parens around a context are not reproduced. This will require an
AST change and will be done in a separate patch.
2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
to prevent noise in the output.
I am not sure what the desired behaviour in this case is, so have left
it as before. Test Ppr047 is marked as expected fail for this.
3. Apart from in a context, the ParsedSource AST keeps all the parens from
the original source. Something is happening in the renamer to remove the
parens around visible type application, causing T12530 to fail, as the
dumped splice decl is after the renamer.
This needs to be fixed by keeping the parens, but I do not know where they
are being removed. I have amended the test to pass, by removing the parens
in the expected output.
Test Plan: ./validate
Reviewers: goldfire, mpickering, simonpj, bgamari, austin
Reviewed By: simonpj, bgamari
Subscribers: simonpj, goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D2752
GHC Trac Issues: #3384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug, exposed by Trac #12562 was very obscure, and has been
lurking for a long time. What happened was that, in the
worker/wrapper split
a tyvar binder for a worker function
accidentally shadowed an in-scope term variable
that was mentioned in the body of the function
It's jolly hard to provoke, so I have not even attempted to make
a test case. There's a Note [Freshen WW arguments] to explain.
Interestingly, fixing the bug (which meant fresher type variables)
revealed a second lurking bug: I'd failed to apply the substitution to
the coercion in the second last case of mkWWArgs, which introduces a
Cast.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a complementary change to
a48de37dcca98e7d477040b0ed298bcd1b3ab303
restore -fmax-worker-args handling (Trac #11565)
I don't have a small example but I've noticed another
discrepancy when was profiling GHC for performance
cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr
was specialised by 'spec_one' down to a function with arity 159.
As a result 'perf record' pointed at it as at slowest
function in whole ghc library.
I've extended -fmax-worker-args effect to 'spec_one'
as it does the same worker/wrapper split to push
arguments to the heap.
The change decreases heap usage on a synth.bash benchmark
(Trac #9221) from 67G down to 64G (-4%). Benchmark runtime
decreased from 14.5 s down to 14.s (-7%).
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Reviewers: ezyang, simonpj, austin, goldfire, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2507
GHC Trac Issues: #11565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
maxWorkerArgs handling was accidentally lost 3 years ago
in a major update of demand analysis
commit 0831a12ea2fc73c33652eeec1adc79fa19700578
Old regression is noticeable as:
- code bloat (requires stack reshuffling)
- compilation slowdown (more code to optimise/generate)
- and increased heap usage (DynFlags unboxing/reboxing?)
On a simple compile benchmark this change causes heap
allocation drop from 70G don to 67G (ghc perf build).
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Reviewers: simonpj, ezyang, goldfire, austin, bgamari
Reviewed By: simonpj, ezyang
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2503
GHC Trac Issues: #11565
|
|
|
|
|
| |
indicating that it is bottom. This should help making the "empty cases"
lint error give less false alarms.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements primitive unboxed sum types, as described in
https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.
Main changes are:
- Add new syntax for unboxed sums types, terms and patterns. Hidden
behind `-XUnboxedSums`.
- Add unlifted unboxed sum type constructors and data constructors,
extend type and pattern checkers and desugarer.
- Add new RuntimeRep for unboxed sums.
- Extend unarise pass to translate unboxed sums to unboxed tuples right
before code generation.
- Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
code generation when sum values are involved.
- Add user manual section for unboxed sums.
Some other changes:
- Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
`MultiValAlt` to be able to use those with both sums and tuples.
- Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
wrong, given an `Any` `TyCon`, there's no way to tell what its kind
is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.
- Fix some bugs on the way: #12375.
Not included in this patch:
- Update Haddock for new the new unboxed sum syntax.
- `TemplateHaskell` support is left as future work.
For reviewers:
- Front-end code is mostly trivial and adapted from unboxed tuple code
for type checking, pattern checking, renaming, desugaring etc.
- Main translation routines are in `RepType` and `UnariseStg`.
Documentation in `UnariseStg` should be enough for understanding
what's going on.
Credits:
- Johan Tibell wrote the initial front-end and interface file
extensions.
- Simon Peyton Jones reviewed this patch many times, wrote some code,
and helped with debugging.
Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
simonmar, hvr, erikd
Reviewed By: simonpj
Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D2259
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As explained in the comment it will cause changes in
inlining if we don't suppress them.
Test Plan: ./validate
Reviewers: bgamari, austin, simonpj, goldfire, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2203
GHC Trac Issues: #4012
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was causing trouble as we had to remember when to use "unLifted"
and when to use "unlifted".
"unlifted" is used instead of "unLifted" as it's a single word.
Reviewers: austin, hvr, goldfire, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Certain syntactic elements have integers in them, such as fixity
specifications, SPECIALISE pragmas and so on.
The lexer will accept mult-radix literals, with arbitrary leading zeros
in these.
Bring in a SourceText field to each affected AST element to capture the
original literal text for use with API Annotations.
Affected hsSyn elements are
```
-- See note [Pragma source text]
data Activation = NeverActive
| AlwaysActive
| ActiveBefore SourceText PhaseNum
-- Active only *strictly before* this phase
| ActiveAfter SourceText PhaseNum
-- Active in this phase and later
deriving( Eq, Data, Typeable )
-- Eq used in comparing rules in HsDecls
data Fixity = Fixity SourceText Int FixityDirection
-- Note [Pragma source text]
deriving (Data, Typeable)
```
and
```
| HsTickPragma -- A pragma introduced tick
SourceText -- Note [Pragma source text] in BasicTypes
(StringLiteral,(Int,Int),(Int,Int))
-- external span for this tick
((SourceText,SourceText),(SourceText,SourceText))
-- Source text for the four integers used in the span.
-- See note [Pragma source text] in BasicTypes
(LHsExpr id)
```
Updates haddock submodule
Test Plan: ./validate
Reviewers: goldfire, bgamari, austin
Reviewed By: bgamari
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1781
GHC Trac Issues: #11430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: austin, goldfire, simonpj, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D1110
GHC Trac Issues: #10706
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two things here:
* For exceptions-catching primops like catch#, we know
that the main argument function will be called, so
we can use strictApply1Dmd, rather than lazy
Changes in primops.txt.pp
* When a 'case' scrutinises a I/O-performing primop,
the Note [IO hack in the demand analyser] was
throwing away all strictness from the code that
followed.
I found that this was causing quite a bit of unnecessary
reboxing in the (heavily used) function
GHC.IO.Handle.Internals.wantReadableHandle
So this patch prevents the hack applying when the
case scrutinises a primop. See the revised
Note [IO hack in the demand analyser]
Thse two things buy us quite a lot in programs that do a lot of IO.
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
hpg -0.4% -2.9% -0.9% -1.0% +0.0%
reverse-complem -0.4% -10.9% +10.7% +10.9% +0.0%
simple -0.3% -0.0% +26.2% +26.2% +3.7%
sphere -0.3% -6.3% 0.09 0.09 +0.0%
--------------------------------------------------------------------------------
Min -0.7% -10.9% -4.6% -4.7% -1.7%
Max -0.2% +0.0% +26.2% +26.2% +6.5%
Geometric Mean -0.4% -0.3% +2.1% +2.1% +0.1%
I think the increase in runtime for 'simple' is measurement error.
|
|
|
|
|
| |
Lacking this cuased Trac #10658.
The fix is easy; it was a simple omission.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [Add demands for strict constructors].
The new bit is the test for isAbsDmd in addDataConStrictness.
There was a cryptic note that said that this function
should add a seqDmd even for Absent arguments, but that
is definitely a bad thing (as the Note now says), causing
unused arguments to be passed to the worker.
Easy fix!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
- Haddock needs to absorb the change too; so there is a submodule update
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts multiple commits from Simon:
- 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359
- a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403
- c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248
- eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first
- ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon
- 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule
- 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet
- a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2)
- a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build
- 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg
- 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints
- 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line
These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
|
|
|
|
|
|
|
|
| |
This fixes a typo in d5773a4939b1feea51ec0db6624c9462751e948a
Teach DmdAnal that coercions are value arguments!
(Trac #10288)
Sorry about that; I'm not sure how it slipped through.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Beofre this commit we never unboxed GADT, even if they
are perfectly civilised products.
This patch liberalises unboxing slightly.
See Note [Product types] in TyCon.
Still to come
- for strictness, we could maybe deal with existentials too
- todo: unboxing constructor arguments
|
|
|
|
|
|
|
|
|
|
|
| |
Coercion variables are used in casts and coercions, so the demand
analyser should jolly well not regard them as absent!
In fact this bug never makes a difference because even absent
unboxed-coercion arguments are passed anyway;
see WwLib.mk_abesnt_let, which returns Nothing for coercion Ids.
But it was simply wrong before and that is never cool.
|