| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
It still lives in darcs, if anyone wants to revive it sometime.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds tuple sections, so that
(x,,z) means \y -> (x,y,z)
Thanks for Max Bolinbroke for doing the hard work.
In the end, instead of using two constructors in HsSyn, I used
just one (still called ExplicitTuple) whose arguments can be
Present (LHsExpr id)
or Missing PostTcType
While I was at it, I did a bit of refactoring too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When matching against a GADT, some of the constructors may be impossible.
For example
data T a where
T1 :: T Int
T2 :: T Bool
T3 :: T a
f :: T Int -> Int
f T1 = 3
f T3 = 4
Here, does not have any missing cases, despite omittting T2, because
T2 :: T Bool.
This patch teaches the overlap checker about GADTs, which happily
turned out to be rather easy even though the overlap checker needs
a serious rewrite.
|
|
|
|
|
|
|
| |
Max spotted that the short-cut rules for desugaring NPats (where
we compare against a literal) were wrong now that we have overloaded
strings.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main purpose of this patch is to fix Trac #3306, by fleshing out the
syntax for GADT-style record declraations so that you have a context in
the type. The new form is
data T a where
MkT :: forall a. Eq a => { x,y :: !a } -> T a
See discussion on the Trac ticket.
The old form is still allowed, but give a deprecation warning.
When we remove the old form we'll also get rid of the one reduce/reduce
error in the grammar. Hurrah!
While I was at it, I failed as usual to resist the temptation to do lots of
refactoring. The parsing of data/type declarations is now much simpler and
more uniform. Less code, less chance of errors, and more functionality.
Took longer than I planned, though.
ConDecl has record syntax, but it was not being used consistently, so I
pushed that through the compiler.
|
|
|
|
|
|
| |
- converting a THSyn FFI declaration to HsDecl was broken; fixed
- pretty-printing of FFI declarations was variously bogus; fixed
- there was an unused "library" field in CImport; removed
|
|
|
|
| |
We don't handle "foreign import prim" in TH stuff.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike normal foreign imports which desugar into a separate worker and
wrapper, we use just a single wrapper decleration. The representation
in Core of the call is currently as a foreign call. This means the
args are all treated as fully strict. This is ok at the moment because
we restrict the types for foreign import prim to be of unboxed types,
however in future we may want to make prim imports be the normal cmm
calling convention for Haskell functions, in which case we would not
be able to assume all args are strict. At that point it may make more
sense to represent cmm/prim calls distinct from foreign calls, and
more like the we the existing PrimOp calls are handled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Roman found situations where he had
case (f n) of _ -> e
where he knew that f (which was strict in n) would terminate if n did.
Notice that the result of (f n) is discarded. So it makes sense to
transform to
case n of _ -> e
Rather than attempt some general analysis to support this, I've added
enough support that you can do this using a rewrite rule:
RULE "f/seq" forall n. seq (f n) e = seq n e
You write that rule. When GHC sees a case expression that discards
its result, it mentally transforms it to a call to 'seq' and looks for
a RULE. (This is done in Simplify.rebuildCase.) As usual, the
correctness of the rule is up to you.
This patch implements the extra stuff. I have not documented it explicitly
in the user manual yet... let's see how useful it is first.
The patch looks bigger than it is, because
a) Comments; see esp MkId Note [seqId magic]
b) Some refactoring. Notably, I moved the special desugaring for
seq from MkCore back into DsUtils where it properly belongs.
(It's really a desugaring thing, not a CoreSyn invariant.)
c) Annoyingly, in a RULE left-hand side we need to be careful that
the magical desugaring done in MkId Note [seqId magic] item (c)
is *not* done on the LHS of a rule. Or rather, we arrange to
un-do it, in DsBinds.decomposeRuleLhs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you have a (\s::String -> ....[| s |]....), the string
's' is lifted. We used to get a chain of single-character
Cons nodes, correct but lots and lots of code.
This patch arranges to optimise that to a string literal. It does
so in two places:
a) In TcExpr, if we know that s::String, we generate liftString directly
b) In DsMeta, if we find a list of character literals, we convert to
a string. This catches a few cases that (a) does not
There an accompanying patch in the template-haskell package,
adding Language.Haskell.TH.Syntax.liftString
|
|
|
|
|
| |
This showed up when converting ds057 to follow the new bang pattern rules,
in #2806.
|
|
|
|
|
| |
This avoids some showSDoc's where the String then gets converted back
into an SDoc.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While I was looking at the desugaring of pattern matching (fixing
Trac #3126) I finally got around to fixing another long-standing bug:
when matching in a record pattern, GHC should match left-to-right in
the programmer-specfied order, *not* left-to-right positionally in
the original record declaration.
Needless to say, that requires a little more code.
See Note [Record patterns] in MatchCon.lhs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Claus Reinke uncovered a long-standing bug in GHC, whereby we were
combining the pattern-match on overloaded literals, missing the fact
that an intervening pattern (for a different literal) might also
match. (If someone had a very odd implementation of fromInteger!)
See Note [Grouping overloaded literal patterns] in Match.lhs
If this merges smoothly to 6.10, go for it, but it's very much
a corner case.
Thank you Claus!
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds an optional CONLIKE modifier to INLINE/NOINLINE pragmas,
{-# NOINLINE CONLIKE [1] f #-}
The effect is to allow applications of 'f' to be expanded in a potential
rule match. Example
{-# RULE "r/f" forall v. r (f v) = f (v+1) #-}
Consider the term
let x = f v in ..x...x...(r x)...
Normally the (r x) would not match the rule, because GHC would be scared
about duplicating the redex (f v). However the CONLIKE modifier says to
treat 'f' like a constructor in this situation, and "look through" the
unfolding for x. So (r x) fires, yielding (f (v+1)).
The main changes are:
- Syntax
- The inlinePragInfo field of an IdInfo has a RuleMatchInfo
component, which records whether or not the Id is CONLIKE.
Of course, this needs to be serialised in interface files too.
- The occurrence analyser (OccAnal) and simplifier (Simplify) treat
CONLIKE thing like constructors, by ANF-ing them
- New function coreUtils.exprIsExpandable is like exprIsCheap, but
additionally spots applications of CONLIKE functions
- A CoreUnfolding has a field that caches exprIsExpandable
- The rule matcher consults this field. See
Note [Expanding variables] in Rules.lhs.
On the way I fixed a lurking variable bug in the way variables are
expanded. See Note [Do not expand locally-bound variables] in
Rule.lhs. I also did a bit of reformatting and refactoring in
Rules.lhs, so the module has more lines changed than are really
different.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to generated things like:
extern StgWordArray (newCAF) __attribute__((aligned (8)));
((void (*)(void *))(W_)&newCAF)((void *)R1.w);
(which is to say, pretend that newCAF is some data, then cast it to a
function and call it).
This goes wrong on at least IA64, where:
A function pointer on the ia64 does not point to the first byte of
code. Intsead, it points to a structure that describes the function.
The first quadword in the structure is the address of the first byte
of code
so we end up dereferencing function pointers one time too many, and
segfaulting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rolling back:
Fri Dec 5 16:54:00 GMT 2008 simonpj@microsoft.com
* Completely new treatment of INLINE pragmas (big patch)
This is a major patch, which changes the way INLINE pragmas work.
Although lots of files are touched, the net is only +21 lines of
code -- and I bet that most of those are comments!
HEADS UP: interface file format has changed, so you'll need to
recompile everything.
There is not much effect on overall performance for nofib,
probably because those programs don't make heavy use of INLINE pragmas.
Program Size Allocs Runtime Elapsed
Min -11.3% -6.9% -9.2% -8.2%
Max -0.1% +4.6% +7.5% +8.9%
Geometric Mean -2.2% -0.2% -1.0% -0.8%
(The +4.6% for on allocs is cichelli; see other patch relating to
-fpass-case-bndr-to-join-points.)
The old INLINE system
~~~~~~~~~~~~~~~~~~~~~
The old system worked like this. A function with an INLINE pragam
got a right-hand side which looked like
f = __inline_me__ (\xy. e)
The __inline_me__ part was an InlineNote, and was treated specially
in various ways. Notably, the simplifier didn't inline inside an
__inline_me__ note.
As a result, the code for f itself was pretty crappy. That matters
if you say (map f xs), because then you execute the code for f,
rather than inlining a copy at the call site.
The new story: InlineRules
~~~~~~~~~~~~~~~~~~~~~~~~~~
The new system removes the InlineMe Note altogether. Instead there
is a new constructor InlineRule in CoreSyn.Unfolding. This is a
bit like a RULE, in that it remembers the template to be inlined inside
the InlineRule. No simplification or inlining is done on an InlineRule,
just like RULEs.
An Id can have an InlineRule *or* a CoreUnfolding (since these are two
constructors from Unfolding). The simplifier treats them differently:
- An InlineRule is has the substitution applied (like RULES) but
is otherwise left undisturbed.
- A CoreUnfolding is updated with the new RHS of the definition,
on each iteration of the simplifier.
An InlineRule fires regardless of size, but *only* when the function
is applied to enough arguments. The "arity" of the rule is specified
(by the programmer) as the number of args on the LHS of the "=". So
it makes a difference whether you say
{-# INLINE f #-}
f x = \y -> e or f x y = e
This is one of the big new features that InlineRule gives us, and it
is one that Roman really wanted.
In contrast, a CoreUnfolding can fire when it is applied to fewer
args than than the function has lambdas, provided the result is small
enough.
Consequential stuff
~~~~~~~~~~~~~~~~~~~
* A 'wrapper' no longer has a WrapperInfo in the IdInfo. Instead,
the InlineRule has a field identifying wrappers.
* Of course, IfaceSyn and interface serialisation changes appropriately.
* Making implication constraints inline nicely was a bit fiddly. In
the end I added a var_inline field to HsBInd.VarBind, which is why
this patch affects the type checker slightly
* I made some changes to the way in which eta expansion happens in
CorePrep, mainly to ensure that *arguments* that become let-bound
are also eta-expanded. I'm still not too happy with the clarity
and robustness fo the result.
* We now complain if the programmer gives an INLINE pragma for
a recursive function (prevsiously we just ignored it). Reason for
change: we don't want an InlineRule on a LoopBreaker, because then
we'd have to check for loop-breaker-hood at occurrence sites (which
isn't currenlty done). Some tests need changing as a result.
This patch has been in my tree for quite a while, so there are
probably some other minor changes.
M ./compiler/basicTypes/Id.lhs -11
M ./compiler/basicTypes/IdInfo.lhs -82
M ./compiler/basicTypes/MkId.lhs -2 +2
M ./compiler/coreSyn/CoreFVs.lhs -2 +25
M ./compiler/coreSyn/CoreLint.lhs -5 +1
M ./compiler/coreSyn/CorePrep.lhs -59 +53
M ./compiler/coreSyn/CoreSubst.lhs -22 +31
M ./compiler/coreSyn/CoreSyn.lhs -66 +92
M ./compiler/coreSyn/CoreUnfold.lhs -112 +112
M ./compiler/coreSyn/CoreUtils.lhs -185 +184
M ./compiler/coreSyn/MkExternalCore.lhs -1
M ./compiler/coreSyn/PprCore.lhs -4 +40
M ./compiler/deSugar/DsBinds.lhs -70 +118
M ./compiler/deSugar/DsForeign.lhs -2 +4
M ./compiler/deSugar/DsMeta.hs -4 +3
M ./compiler/hsSyn/HsBinds.lhs -3 +3
M ./compiler/hsSyn/HsUtils.lhs -2 +7
M ./compiler/iface/BinIface.hs -11 +25
M ./compiler/iface/IfaceSyn.lhs -13 +21
M ./compiler/iface/MkIface.lhs -24 +19
M ./compiler/iface/TcIface.lhs -29 +23
M ./compiler/main/TidyPgm.lhs -55 +49
M ./compiler/parser/ParserCore.y -5 +6
M ./compiler/simplCore/CSE.lhs -2 +1
M ./compiler/simplCore/FloatIn.lhs -6 +1
M ./compiler/simplCore/FloatOut.lhs -23
M ./compiler/simplCore/OccurAnal.lhs -36 +5
M ./compiler/simplCore/SetLevels.lhs -59 +54
M ./compiler/simplCore/SimplCore.lhs -48 +52
M ./compiler/simplCore/SimplEnv.lhs -26 +22
M ./compiler/simplCore/SimplUtils.lhs -28 +4
M ./compiler/simplCore/Simplify.lhs -91 +109
M ./compiler/specialise/Specialise.lhs -15 +18
M ./compiler/stranal/WorkWrap.lhs -14 +11
M ./compiler/stranal/WwLib.lhs -2 +2
M ./compiler/typecheck/Inst.lhs -1 +3
M ./compiler/typecheck/TcBinds.lhs -17 +27
M ./compiler/typecheck/TcClassDcl.lhs -1 +2
M ./compiler/typecheck/TcExpr.lhs -4 +6
M ./compiler/typecheck/TcForeign.lhs -1 +1
M ./compiler/typecheck/TcGenDeriv.lhs -14 +13
M ./compiler/typecheck/TcHsSyn.lhs -3 +2
M ./compiler/typecheck/TcInstDcls.lhs -5 +4
M ./compiler/typecheck/TcRnDriver.lhs -2 +11
M ./compiler/typecheck/TcSimplify.lhs -10 +17
M ./compiler/vectorise/VectType.hs +7
Mon Dec 8 12:43:10 GMT 2008 simonpj@microsoft.com
* White space only
M ./compiler/simplCore/Simplify.lhs -2
Mon Dec 8 12:48:40 GMT 2008 simonpj@microsoft.com
* Move simpleOptExpr from CoreUnfold to CoreSubst
M ./compiler/coreSyn/CoreSubst.lhs -1 +87
M ./compiler/coreSyn/CoreUnfold.lhs -72 +1
Mon Dec 8 17:30:18 GMT 2008 simonpj@microsoft.com
* Use CoreSubst.simpleOptExpr in place of the ad-hoc simpleSubst (reduces code too)
M ./compiler/deSugar/DsBinds.lhs -50 +16
Tue Dec 9 17:03:02 GMT 2008 simonpj@microsoft.com
* Fix Trac #2861: bogus eta expansion
Urghlhl! I "tided up" the treatment of the "state hack" in CoreUtils, but
missed an unexpected interaction with the way that a bottoming function
simply swallows excess arguments. There's a long
Note [State hack and bottoming functions]
to explain (which accounts for most of the new lines of code).
M ./compiler/coreSyn/CoreUtils.lhs -16 +53
Mon Dec 15 10:02:21 GMT 2008 Simon Marlow <marlowsd@gmail.com>
* Revert CorePrep part of "Completely new treatment of INLINE pragmas..."
The original patch said:
* I made some changes to the way in which eta expansion happens in
CorePrep, mainly to ensure that *arguments* that become let-bound
are also eta-expanded. I'm still not too happy with the clarity
and robustness fo the result.
Unfortunately this change apparently broke some invariants that were
relied on elsewhere, and in particular lead to panics when compiling
with profiling on.
Will re-investigate in the new year.
M ./compiler/coreSyn/CorePrep.lhs -53 +58
M ./configure.ac -1 +1
Mon Dec 15 12:28:51 GMT 2008 Simon Marlow <marlowsd@gmail.com>
* revert accidental change to configure.ac
M ./configure.ac -1 +1
|
|
|
|
|
|
|
| |
In particular:
-fauto-sccs-on-all-toplevs -auto-all -no-auto-all
-fauto-sccs-on-exported-toplevs -auto -no-auto
-fauto-sccs-on-individual-cafs -caf-all -no-caf-all
|
|
|
|
| |
too)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a major patch, which changes the way INLINE pragmas work.
Although lots of files are touched, the net is only +21 lines of
code -- and I bet that most of those are comments!
HEADS UP: interface file format has changed, so you'll need to
recompile everything.
There is not much effect on overall performance for nofib,
probably because those programs don't make heavy use of INLINE pragmas.
Program Size Allocs Runtime Elapsed
Min -11.3% -6.9% -9.2% -8.2%
Max -0.1% +4.6% +7.5% +8.9%
Geometric Mean -2.2% -0.2% -1.0% -0.8%
(The +4.6% for on allocs is cichelli; see other patch relating to
-fpass-case-bndr-to-join-points.)
The old INLINE system
~~~~~~~~~~~~~~~~~~~~~
The old system worked like this. A function with an INLINE pragam
got a right-hand side which looked like
f = __inline_me__ (\xy. e)
The __inline_me__ part was an InlineNote, and was treated specially
in various ways. Notably, the simplifier didn't inline inside an
__inline_me__ note.
As a result, the code for f itself was pretty crappy. That matters
if you say (map f xs), because then you execute the code for f,
rather than inlining a copy at the call site.
The new story: InlineRules
~~~~~~~~~~~~~~~~~~~~~~~~~~
The new system removes the InlineMe Note altogether. Instead there
is a new constructor InlineRule in CoreSyn.Unfolding. This is a
bit like a RULE, in that it remembers the template to be inlined inside
the InlineRule. No simplification or inlining is done on an InlineRule,
just like RULEs.
An Id can have an InlineRule *or* a CoreUnfolding (since these are two
constructors from Unfolding). The simplifier treats them differently:
- An InlineRule is has the substitution applied (like RULES) but
is otherwise left undisturbed.
- A CoreUnfolding is updated with the new RHS of the definition,
on each iteration of the simplifier.
An InlineRule fires regardless of size, but *only* when the function
is applied to enough arguments. The "arity" of the rule is specified
(by the programmer) as the number of args on the LHS of the "=". So
it makes a difference whether you say
{-# INLINE f #-}
f x = \y -> e or f x y = e
This is one of the big new features that InlineRule gives us, and it
is one that Roman really wanted.
In contrast, a CoreUnfolding can fire when it is applied to fewer
args than than the function has lambdas, provided the result is small
enough.
Consequential stuff
~~~~~~~~~~~~~~~~~~~
* A 'wrapper' no longer has a WrapperInfo in the IdInfo. Instead,
the InlineRule has a field identifying wrappers.
* Of course, IfaceSyn and interface serialisation changes appropriately.
* Making implication constraints inline nicely was a bit fiddly. In
the end I added a var_inline field to HsBInd.VarBind, which is why
this patch affects the type checker slightly
* I made some changes to the way in which eta expansion happens in
CorePrep, mainly to ensure that *arguments* that become let-bound
are also eta-expanded. I'm still not too happy with the clarity
and robustness fo the result.
* We now complain if the programmer gives an INLINE pragma for
a recursive function (prevsiously we just ignored it). Reason for
change: we don't want an InlineRule on a LoopBreaker, because then
we'd have to check for loop-breaker-hood at occurrence sites (which
isn't currenlty done). Some tests need changing as a result.
This patch has been in my tree for quite a while, so there are
probably some other minor changes.
|
|
|
|
|
|
|
|
|
|
| |
The new static flag -fsimple-list-literals makes ExplicitList literals
be desugared in the straightforward way, rather than using 'build' as
now. See SLPJ comments with Note [Desugaring explicit lists].
I don't expect this flag to be used by users (hence no docs). It's just
there to let me try the performance effects of switching on and off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This merge does not turn on the new codegen (which only compiles
a select few programs at this point),
but it does introduce some changes to the old code generator.
The high bits:
1. The Rep Swamp patch is finally here.
The highlight is that the representation of types at the
machine level has changed.
Consequently, this patch contains updates across several back ends.
2. The new Stg -> Cmm path is here, although it appears to have a
fair number of bugs lurking.
3. Many improvements along the CmmCPSZ path, including:
o stack layout
o some code for infotables, half of which is right and half wrong
o proc-point splitting
|
|
|
|
|
| |
Particularly boolean expresions: the conditional of an 'if', and
guards, were missing their free variables.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch, written by Max Bolingbroke, does two things
1. It adds a new CoreM monad (defined in simplCore/CoreMonad),
which is used as the top-level monad for all the Core-to-Core
transformations (starting at SimplCore). It supports
* I/O (for debug printing)
* Unique supply
* Statistics gathering
* Access to the HscEnv, RuleBase, Annotations, Module
The patch therefore refactors the top "skin" of every Core-to-Core
pass, but does not change their functionality.
2. It adds a completely new facility to GHC: Core "annotations".
The idea is that you can say
{#- ANN foo (Just "Hello") #-}
which adds the annotation (Just "Hello") to the top level function
foo. These annotations can be looked up in any Core-to-Core pass,
and are persisted into interface files. (Hence a Core-to-Core pass
can also query the annotations of imported things.) Furthermore,
a Core-to-Core pass can add new annotations (eg strictness info)
of its own, which can be queried by importing modules.
The design of the annotation system is somewhat in flux. It's
designed to work with the (upcoming) dynamic plug-ins mechanism,
but is meanwhile independently useful.
Do not merge to 6.10!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ganesh wanted to update records that involve existentials. That
seems reasonable to me, and this patch covers existentials, GADTs,
and data type families.
The restriction is that
The types of the updated fields may mention only the
universally-quantified type variables of the data constructor
This doesn't allow everything in #2595 (it allows 'g' but not 'f' in
the ticket), but it gets a lot closer.
Lots of the new lines are comments!
|
| |
|
|
|
|
|
|
| |
nameModule fails on an InternalName. These ASSERTS tell you
which call failed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does a lot of tidying up of the way that dead variables are
handled in Core. Just the sort of thing to do on an aeroplane.
* The tricky "binder-swap" optimisation is moved from the Simplifier
to the Occurrence Analyser. See Note [Binder swap] in OccurAnal.
This is really a nice change. It should reduce the number of
simplifier iteratoins (slightly perhaps). And it means that
we can be much less pessimistic about zapping occurrence info
on binders in a case expression.
* For example:
case x of y { (a,b) -> e }
Previously, each time around, even if y,a,b were all dead, the
Simplifier would pessimistically zap their OccInfo, so that we
can't see they are dead any more. As a result virtually no
case expression ended up with dead binders. This wasn't Bad
in itself, but it always felt wrong.
* I added a check to CoreLint to check that a dead binder really
isn't used. That showed up a couple of bugs in CSE. (Only in
this sense -- they didn't really matter.)
* I've changed the PprCore printer to print "_" for a dead variable.
(Use -dppr-debug to see it again.) This reduces clutter quite a
bit, and of course it's much more useful with the above change.
* Another benefit of the binder-swap change is that I could get rid of
the Simplifier hack (working, but hacky) in which the InScopeSet was
used to map a variable to a *different* variable. That allowed me
to remove VarEnv.modifyInScopeSet, and to simplify lookupInScopeSet
so that it doesn't look for a fixpoint. This fixes no bugs, but
is a useful cleanup.
* Roman pointed out that Id.mkWildId is jolly dangerous, because
of its fixed unique. So I've
- localied it to MkCore, where it is private (not exported)
- renamed it to 'mkWildBinder' to stress that you should only
use it at binding sites, unless you really know what you are
doing
- provided a function MkCore.mkWildCase that emodies the most
common use of mkWildId, and use that elsewhere
So things are much better
* A knock-on change is that I found a common pattern of localising
a potentially global Id, and made a function for it: Id.localiseId
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This is just a tidy-up. Previously we were calling occurAnalyse
twice on each LHS which was silly and a bit unclean too.
This patch should have no overall effect, though.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes an important change to the way that dictionary
functions are handled. Before, they were unconditionally marked
INLIINE, but all the code written by the user in the instance
was inside that unconditionally-inlined function. Result: massive
code bloat in programs that use complicated instances.
This patch make instances behave rather as if all the methods
were written in separate definitions. That dramatically reduces
bloat. The new plan is described in TcInstDcls
Note [How instance declarations are translated]
Everything validates. The major code-bloat bug is squashed: in particular
DoCon is fine now (Trac #2328) and I believe that #955 is also better.
Nofib results:
Binary sizes
-1 s.d. +2.5%
+1 s.d. +3.1%
Average +2.8%
Allocations
-1 s.d. -6.4%
+1 s.d. +2.5%
Average -2.0%
Note that 2% improvement. Some programs improve by 20% (rewrite)!
Two get slightly worse: pic (2.1%), and gameteb (3.2%), but all others
improve or stay the same.
I am not absolutely 100% certain that all the corners are correct; for
example, when default methods are marked INLINE, are they inlined? But
overall it's better.
It's nice that the patch also removes a lot of code. I deleted some
out of date comments, but there's something like 100 fewer lines of
code in the new version! (In the line counts below, there are a lot
of new comments.)
|
|
|
|
|
|
|
|
|
| |
The problem here was that were were quantifying over an *External* Name,
which causes no end of confusion. See Note [Const rule dicts] in DsBinds.
The fix is very easy, I'm happy to say.
|