| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
by elaborating the domain a bit.
|
| |
|
|
|
|
|
|
|
| |
This also sets precedence for testing internals of GHC directly, i.e.
without trying to come up with Haskell code and observable effects.
Let's see how that goes.
I put all the tests (including those where the analysis could do better)
in one file because starting the GHC API is quite slow.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This analysis finds out if a let-bound expression with lower manifest
arity than type arity is always called with more arguments, as in that
case eta-expansion is allowed and often viable. The analysis is very
much tailored towards the code generated when foldl is implemented via
foldr; without this analysis doing so would be a very bad idea!
There are other ways to improve foldr/builder-fusion to cope with foldl,
if any of these are implemented then this step can probably be moved to
-O2 to save some compilation times. The current impact of adding this
phase is just below +2% (measured running GHC's "make").
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
by passing the FamInstEnvs all the way down. This closes #7619.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The basic idea here is simple, and described in Note [The interactive package]
in HscTypes, which starts thus:
Note [The interactive package]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Type and class declarations at the command prompt are treated as if
they were defined in modules
interactive:Ghci1
interactive:Ghci2
...etc...
with each bunch of declarations using a new module, all sharing a
common package 'interactive' (see Module.interactivePackageId, and
PrelNames.mkInteractiveModule).
This scheme deals well with shadowing. For example:
ghci> data T = A
ghci> data T = B
ghci> :i A
data Ghci1.T = A -- Defined at <interactive>:2:10
Here we must display info about constructor A, but its type T has been
shadowed by the second declaration. But it has a respectable
qualified name (Ghci1.T), and its source location says where it was
defined.
So the main invariant continues to hold, that in any session an original
name M.T only refers to oe unique thing. (In a previous iteration both
the T's above were called :Interactive.T, albeit with different uniques,
which gave rise to all sorts of trouble.)
This scheme deals nicely with the original problem. It allows us to
eliminate a couple of grotseque hacks
- Note [Outputable Orig RdrName] in HscTypes
- Note [interactive name cache] in IfaceEnv
(both these comments have gone, because the hacks they describe are no
longer necessary). I was also able to simplify Outputable.QueryQualifyName,
so that it takes a Module/OccName as args rather than a Name.
However, matters are never simple, and this change took me an
unreasonably long time to get right. There are some details in
Note [The interactive package] in HscTypes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Joachim and I are committing this onto a branch so that we can share it,
but we expect to do a bit more work before merging it onto head.
Nofib staus:
- Most programs, no change
- A few improve
- A couple get worse (cacheprof, tak, rfib)
Investigating the "get worse" set is what's holding up putting this
on head.
The major issue is this. Consider
map (f g) ys
where f's demand signature looks like
f :: <L,C1(C1(U))> -> <L,U> -> .
So 'f' is not saturated. What demand do we place on g?
Answer
C(C1(U))
That is, the inner C1 should stay, even though f is not saturated.
I found that this made a significant difference in the demand signatures
inferred in GHC.IO, which uses lots of higher-order exception handlers.
I also had to add used-once demand signatures for some of the
'catch' primops, so that we know their handlers are only called once.
|
| |
|
|
|
|
|
|
|
|
| |
This fixes #8540 (again), and simplifies matters a bit more. In
particular, I got rid of ic_sys_vars altogether. Mostly they can just
go in ic_tythings, apart from dfuns, which are readily gettable from
the instances anyway.
See documentation in Note [Initialising the type environment for GHCi]
in TcEnv.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were re-using the super-magical "state token" type (which has
VoidRep and is zero bits wide) for situations in which we simply want
to lambda-abstract over a zero-bit argument. For example, join points:
case (case x of { True -> e1; False -> e2 }) of
Red -> f1
Blue -> True
==>
let $j1 = \voidArg::Void# -> f1
in
case x of
True -> case e1 of
Red -> $j1 void
Blue -> True
False -> case e2 of
Red -> $j1 void
Blue -> True
This patch introduces
* The new primitive type GHC.Prim.Void#, with PrimRep = VoidRep
* A new global Id GHC.Prim.voidPrimId :: Void#.
This has no binding because the code generator drops it,
but is used as an argument (eg in the call of $j1)
* A new local Id, MkId.voidArgId, which can be lambda-bound
when you need to lambda-abstract over it.
and uses them throughout.
Now the State# thing is used only when we need state!
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The presenting issue was that we were never eta-expanding
f (\x -> case x of (a,b) -> \s -> blah)
and that meant we were allocating two lambdas instead of one.
See Note [Eta expanding lambdas] in SimplUtils.
However I didn't want to eta expand the lambda, and then try all over
again for tryEtaExpandRhs. Yet the latter is important in the context
of a let-binding it can do simple arity analysis. So I ended up
refactoring CallCtxt so that it tells when we are on the RHS of a let.
I also moved findRhsArity from SimplUtils to CoreArity.
Performance increases nicely. Here are the ones where allocation improved
by more than 0.5%. Notice the nice decrease in binary size too.
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
ansi -2.3% -0.9% 0.00 0.00 +0.0%
bspt -2.1% -9.7% 0.01 0.01 -33.3%
fasta -1.8% -11.7% -3.4% -3.6% +0.0%
fft -1.9% -1.3% 0.06 0.06 +11.1%
reverse-complem -1.9% -18.1% -1.9% -2.8% +0.0%
sphere -1.8% -4.5% 0.09 0.09 +0.0%
transform -1.8% -2.3% -4.6% -3.1% +0.0%
--------------------------------------------------------------------------------
Min -3.0% -18.1% -13.9% -14.6% -35.7%
Max -1.3% +0.0% +7.7% +7.7% +50.0%
Geometric Mean -1.9% -0.6% -2.1% -2.1% -0.2%
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a bad omission in CSE, thanks to 'michaelt' for spotting
it, and correctly identifying the fix (in cseRhs). The trouble was with
x1 = C a b
x2 = C x1 b
y1 = C a b
y2 = C y1 b
we were not commoning up y2=x2, because we failed to substitute y1:=x1,
so y2's RHS looked different to x2's
I also refactoring, so taht the cs_map in a CSEnv map is
cs_map :: CoreMap (OutExpr, Id)
instead of
cs_map :: CoreMap (OutExpr, OutExpr)
Much nicer!
This doesn't make much difference to allocation, but it gives a surprisingly
big benefit to binary size.
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
ansi -1.7% -0.8% 0.00 0.00 +0.0%
bspt -1.6% -1.5% 0.01 0.01 +0.0%
cacheprof -1.8% -0.2% +1.6% +1.9% +2.7%
fft -1.4% -1.3% 0.06 0.06 +11.1%
ida -1.4% -1.0% 0.12 0.12 +0.0%
rfib -1.4% -0.1% 0.03 0.03 +0.0%
scs -1.6% -0.1% +1.5% +1.5% +0.0%
spectral-norm -1.3% -0.1% -0.2% -0.2% +0.0%
tak -1.4% -0.1% 0.02 0.02 +0.0%
veritas -1.4% -0.1% 0.00 0.00 +0.0%
--------------------------------------------------------------------------------
Min -2.5% -1.5% -11.8% -11.8% -8.0%
Max -1.0% +0.0% +2.7% +2.5% +11.1%
Geometric Mean -1.3% -0.1% -2.6% -2.6% +0.0%
|
| |
|
|
|
|
| |
and add new, simpler topNormaliseType
This is just a minor refactoring
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in #8276, this code was somewhat broken because while you
could always revert the actual argument list, you can never revert the
CAFs upon which they are based - so really this didn't buy you much.
However, Haddock in particular expects to be able to parse GHC flags,
including static flags, and used this code to do so. In its place, we
instead have discardStaticFlags, which will safely remove any of the
remaining 5 flags from a list of arguments. Haddock instead discards
these, as they aren't related to anything it does anyway (mostly
controlling debugging output and some basic optimizer phases.)
This fixes #8276. In the future, we will eventually completely remove
the remaining StaticFlags, removing the need for this fix. Unfortunately
these changes will be quite invasive and require more time.
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
| |
Authored-by: Gergely Risko <gergely@risko.hu>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In 6579a6c we removed existing comparison primops and introduced new ones
returning Int# instead of Bool. This commit (and associated commits in
array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and
template-haskell) restores old names of primops. This allows us to keep
our API cleaner at the price of not having backwards compatibility.
This patch also temporalily disables fix for #8317 (optimization of
tagToEnum# at Core level). We need to fix #8326 first, otherwise
our primops code will be very slow.
|
| |
|
|
| |
See Note [Optimising tagToEnum#] in Simplify
|
| |
|
|
|
| |
Authored-by: David Luposchainsky <dluposchainsky@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original problem was that we weren't bringing varaibles bound in the
interactive context into scope before Linting the result of a top-level
declaration in GHCi. (We were doing this for expressions.)
Moreover I found that we weren't Linting the result of desugaring
a GHCi expression, which we really should be doing.
It took me a bit of time to unravel all this, and I did some refactoring
to make it easier next time.
* CoreMonad contains the Lint wrappers that get the right
environments into place. It always had endPass and lintPassResult
(which Lints bindings), but now it has lintInteractiveExpr.
* Both use a common function CoreMonad.interactiveInScope to find
those in-scope variables.
Quite a bit of knock-on effects from this, but nothing exciting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part of Nick Frisby's patch (c080f727ba5f83921b842fcff71e9066adbdc250)
for late demand-analysis removed the over-zealous short-cut whereby
strictness wrappers were not spelled out in detail in interface files.
This patch completes the process by
* removing InlineWrapper from UnfoldingSource
* removing IfWrapper from IfaceUnfolding
There was a tiny bit of special ad-hocery for wrappers, in OccurAnal,
but fortunately that too turns out to be rendered irrelevant by
the more uniform treatment, and after that there was no need
to remember which functions are wrappers.
|
| | |
|
| |
|
|
| |
cf http://ghc.haskell.org/trac/ghc/wiki/LateDmd
|
| |
|
|
| |
I'd still prefer if a native english speaker would check them.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Roles are a solution to the GeneralizedNewtypeDeriving type-safety
problem.
Roles were first described in the "Generative type abstraction" paper,
by Stephanie Weirich, Dimitrios Vytiniotis, Simon PJ, and Steve Zdancewic.
The implementation is a little different than that paper. For a quick
primer, check out Note [Roles] in Coercion. Also see
http://ghc.haskell.org/trac/ghc/wiki/Roles
and
http://ghc.haskell.org/trac/ghc/wiki/RolesImplementation
For a more formal treatment, check out docs/core-spec/core-spec.pdf.
This fixes Trac #1496, #4846, #7148.
|
| | |
|
| |
|
|
| |
279ac9f66a83203448b279ea478b2cc1dafbd35d.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In many places, 'splitUniqSupply' + 'uniqFromSupply' is used to split a
UniqSupply into a Unique and a new UniqSupply. In such places we should
instead use the more efficient and more appropriate
'takeUniqFromSupply' (or equivalent).
Not only is the former method slower, it also generates and throws away
an extra Unique.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
