| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
movss instruction was being used to move the result into the
destination register instead of movsd
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
When making record selectors into ordinary functions (rather than
magial implicit Ids) I forgot that they could therefore show up in
the *local* TcEnv, not the global one. This fixes that problem,
and thereby Trac #3176.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GHCi if you say 'import Foo' meaning to load a package module Foo,
and Foo.hs is found on the search path, then GHCi replies "module Foo
is not loaded", because it knows Foo refers to the source file rather
than the package module, and you haven't loaded that module with
:load.
This is consistent with the usual module-finding semantics. However,
it isn't particularly useful. And it leads to silly problems like not
being able to start GHCi when you happen to be sitting in
libraries/base, because GHCi thinks the Prelude hasn't been loaded.
So now I've made a slight change to the way that 'import M' works: if
M is loaded, then it refers to the loaded module, otherwise it looks
for a package module M. This does what the reporter of #2682 wanted,
and since it turns an error condition into meaningful behaviour it
can't break anything.
The only undesirable consequence is that 'import M' might refer to a
different M than ':load M'. Hopefully that won't lead to confusion.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out we can easily support breakpoints on expressions with
unlifted types, by translating
case tick# of _ -> e
into
let f = \s . case tick# of _ -> e
in f realWorld#
instead of just a plain let-binding. This is the same trick that GHC
uses for abstracting join points of unlifted type.
In #2845, GHC has eta-expanded the tick expression, changing the
result type from IO a to (# State#, a #), which was the reason the
tick was suddenly being ignored. By supporting ticks on unlifted
expressions we can make it work again, although some confusion might
arise because _result will no longer be available (it now has
unboxed-tuple type, so we can't bind it in the environment). The
underlying problem here is that GHC does transformations like
eta-expanding the tick expressions, and there's nothing we can do to
prevent that.
|
| | |
|
| | |
|
| |
|
|
|
| |
My previous patch didn't completely solve the problem.
I believe I got it right this time.
|
| |
|
|
|
| |
Fix a bug in :print affecting data types with unboxed components
|
| |
|
|
|
|
| |
The x86 code generator sometimes generates nop moves like
movl %vI_a %vI_a, but we'll just ignore them for coalescing
purposes instead of emitting an error. It shouldn't hurt anything.
|
| |
|
|
| |
I forgot to record some additional changes.
|
| |
|
|
|
|
|
|
|
|
|
| |
Simon P-J suggested the following simplifications in #3097:
* Allow nested foralls in `ctype` just like in `ctypedoc`.
* Use `gentype` rather than `type` in the LHS of type declarations.
* Inline `type` in `ctype`.
* Rename `gentype` to `type`.
This patch does this. Also, the equivalent thing is done for documented types.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch sligtly re-adjusts the way in which the syntax of types
is handled:
* In the lexer, '.' and '*' are always accepted in types
(previously it was conditional). This things can't mean
anything else in H98, which is the only reason for doing things
conditionally in the lexer.
* As a result '.' in types is never treated as an operator.
Instead, lacking a 'forall' keyword, it turns into a plain parse error.
* Test for -XKindSignatures in the renamer when processing
a) type variable bindings
b) types with sigs (ty :: kind-sig)
* Make -XKindSignatures be implied by -XTypeFamilies
Previously this was buried in the conditonal lexing of '*'
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of these things is not like the others:
stdPattern :: [LRep] -> Maybe StgHalfWord
stdPattern reps
= case reps of
[] -> Just ARG_NONE -- just void args, probably
[N] -> Just ARG_N
[P] -> Just ARG_N
[F] -> Just ARG_F
[D] -> Just ARG_D
[L] -> Just ARG_L
Today's debugging session was brought to you by the letter P.
|
| |
|
|
|
|
|
|
|
| |
entry point
- Block concat and branch-chain elimination were allowing a function call
to return to the caller's entry point. But that doesn't leave anywhere
for the infotable on the stack, since the SP on return must be the same
as the SP on entry to the procedure.
|
| |
|
|
|
|
| |
- Previously, the node was taken as a parameter, then ignored,
for static closures. Goofy. Now, the vestigial node parameters
are gone.
|
| | |
|
| |
|
|
| |
node argument is managed
|
| | |
|
| | |
|
| |
|
|
| |
making calls
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the result of a long series of nofib-based experiments
to improve GHC's inlining heuristics.
In the end, I'm not sure how worthwhile it all was: I only got a
1% decrease in code size
1% decrease in allocation
and I don't trust the runtime statistics enough to quote.
Still, in doing all this I tidied up the code quite a bit, and
I understand it much better now, so I'm going to commit it.
The main changes are in CoreUnfold, which has lots of new comments.
Other changes:
- litSize moves from Literal to CoreUnfold
- interestingArg moves from SimplUtils to CoreUnfold
- the default unfolding threshold (in StaticFlags)
reduces from 8 to 6 (since the size calculation
has changed a bit)
|
| |
|
|
|
|
|
|
|
|
|
| |
If worker/wrapper decides not to w/w something on the grounds that
it's too small, it should add an INLINE pragma. Otherwise, later
in the day that small thing might now be big, and we'd wish we'd
done the w/w after all. This only made a difference in one nofib
program (bspt), but it's an easy change.
See Note [Don't w/w inline things (a) and (b)]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I found a couple of shortcomings in arity computation, and did
quite a bit of refactoring as a result. Regrettably, I have
forgotten the details, but I do remember that one part was to
do with the infamous "state hack". If we're going to use the
state-hack at all, we'd better do it right.
Anyway I think this is an improvement. The comments are more
up to date too, and more voluminous.
|
| | |
|
| |
|
|
|
|
| |
See Note [Case MFEs]; don't float case expressions from
a strict context.
|
| |
|
|
|
|
|
| |
This patch fixes a rather obscure bug, whereby it's possible
for (case C a b of <alts>) to have altenatives that do not inclue
(C a b)! See Note [Unreachable code] in CoreUtils.
|
| |
|
|
|
|
|
|
|
|
| |
SimplUtils.interestingArg
I'm changing the details of SimplUtils.interstingArg, and don't want to
mess up the way Specialise works, so this patch makes a specilialised
(ha) function, Specialise.interestingDict, that is used locally.
|
| |
|
|
|
|
|
| |
Make idDetails and idInfo into proper functions, rather than record
fields, so that we can report more informatively if you use thenm on
a non-Id.
|
| |
|
|
|
|
|
| |
In the case binder-swap operation (which is done in OccurAnal),
we deliberately use shadowing. But the new shadowing binder should
not inherit any fancy INLINE or NOINLINE pragmas from its parent.
|
| |
|
|
|
|
|
|
|
| |
This patch changes the compilation pipeline flags so that constants
are floated to the top level even in the first full laziness pass.
For some reason this was not done before. Fixing this makes a big
improvement in 'spectral/rewrite', and has zero effect on any other
nofib benchmark.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes the out of memory errors we were getting on sparc
after the following patch:
Fri Mar 13 03:45:16 PDT 2009 Simon Marlow <marlowsd@gmail.com>
* Instead of a separate context-switch flag, set HpLim to zero
Ignore-this: 6c5bbe1ce2c5ef551efe98f288483b0
This reduces the latency between a context-switch being triggered and
the thread returning to the scheduler, which in turn should reduce the
cost of the GC barrier when there are many cores.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now use `ctypedoc` instead of `ctype` for type synonyms. `ctypedoc` was
previously only used for top-level type signatures. This change means that type
synonyms now can contain comments, just like top-level type signatures.
Note:
* I've modified `ctypedoc` so it allows implicit parameters and equational
constraints, just like ctype.
* Since `ctypedoc` allows nested foralls, we now allow that in type synonyms.
* I have inlined some productions into gentypedoc so that there is now a
non-doc version of every production with a 'doc' suffix. (Stylistic change
only, which should make the code easier to follow).
* It would have been nice to simplify the grammar by unifying `ctype` and
ctypedoc` into one production, allowing comments on types everywhere (and
rejecting them after parsing, where necessary). This is however not possible
since it leads to ambiguity. The reason is the support for comments on record
fields:
> data R = R { field :: Int -- ^ comment on the field }
If we allow comments on types here, it's not clear if the comment applies
to 'field' or to 'Int'. So we must use `ctype` to describe the type.
|
| |
|
|
|
| |
This avoids some showSDoc's where the String then gets converted back
into an SDoc.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixing #246 (pattern-match order in record patterns) made GHC go into
a black hole, by changing the order of patterm matching in
TyCon.isProductTyCon! It turned out that GHC had been avoiding the
black hole only by the narrowest of margins up to now!
The black hole concerned the computation of which type constructors
are recursive, in TcTyDecls.calcRecFlags. We now refrain from using
isProductTyCon there, since it triggers the black hole (very
indirectly). See the "YUK YUK" comment in the body of calcRecFlags.
As it turns out, the fact that TyCon.isProductTyCon matched on the
algTcRec field was quite redundant, so I removed that too. However,
without the fix to calcRecFlags, this wouldn't fix the black hole
because of the use of isRecursiveTyCon in BuildTyCl.mkNewTyConRhs.
Anyway, it's fine now.
|
| | |
|
| | |
|
