This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
- 04 Oct, 2006 12 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Note [Recursive unboxing] ~~~~~~~~~~~~~~~~~~~~~~~~~ Be careful not to try to unbox this! data T = MkT !T Int But it's the *argument* type that matters. This is fine: data S = MkS S !Int because Int is non-recursive. Before this patch, we were only doing the unboxing if the *parent* data type was non-recursive (eg that meant S was not unboxed), but that is over-conservative. This showed up with indexed data types (thanks to Roman for finding it) because indexed data types are conservatively regarded as always recursive.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Note [Scrutinee with cast] ~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider this: f = \ t -> case (v `cast` co) of V a b -> a : f t Exactly the same optimistaion (unrolling one call to f) will work here, despite the cast. See mk_alt_env in the Case branch of libCase. This patch does the job. For a change, it was really easy.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Remove ILX from the GHC altogether (although I left the source file IlxGen in case anyone wants to see it)
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
We want the universal and existential tyvars of a data constructor to have distinct OccNames. It's confusing if they don't (in error messages, for example), and with the current way of generating IfaceSyn, it actally generates bogus interface files. (Which bit Roman.) When IfaceSyn is full of Names, this won't matter so much, but it still seems cleaner. This patch adds a 'tidy' step to the generation of DataCon type variables in TcTyClDecls.tcResultType
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
This is part 2 of the patch that improved the interaction of RULES and recursion. It's vital that all Ids that may be referred to from later in the module are marked 'IAmALoopBreaker' because otherwise we may do postInlineUnconditionally, and lose the binding altogether. So I've added a boolean rules-only flag to IAmALoopBreaker. Now we can do inlining for rules-only loop-breakers.
-
simonpj@microsoft.com authored
Note [Case of cast] ~~~~~~~~~~~~~~~~~~~ Consider case (v `cast` co) of x { I# -> ... (case (v `cast` co) of {...}) ... We'd like to eliminate the inner case. We can get this neatly by arranging that inside the outer case we add the unfolding v |-> x `cast` (sym co) to v. Then we should inline v at the inner case, cancel the casts, and away we go This patch does the job, fixing a performance hole reported by Roman.
-
- 03 Oct, 2006 6 commits
-
-
Ian Lynagh authored
-
simonpj@microsoft.com authored
See Trac #683 This patch improves the interaction of recursion and RULES; at least I hope it does. The problem was that a RULE was being treated uniformly like an "extra RHS". This worked badly when you have a non-recursive definition that is made recursive only by RULE. This patch maeks the occurrence analyser know whether a binder is referred to only from RULES (the RulesOnly constructor in OccInfo). Then we can ignore such edges when deciding on the order of bindings in a letrec, and when setting the LoopBreaker flag. The remaining potential problem is this: rec{ f = ...g... ; g = ...f... RULE g True = ... } The RULE for g may not be visible in f's rhs. This is fixable, but not today.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
I had forgotten to bring scoped type variables into scope at an expression type signature, such as e :: forall s. <type> where 's' should scope over the expression e. Like everything to do with scoped type variables, fixing this took an unreasonable amount of work. I'm sure there must be a better way to achitect this! I updated the user manual too. A test is tc213. It would be good to push this into 6.6.1
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Fixes Trac #919
-
- 27 Jul, 2006 1 commit
-
-
David Himmelstrup authored
-
- 01 Oct, 2006 1 commit
-
-
Ian Lynagh authored
-
- 29 Sep, 2006 15 commits
-
-
Simon Marlow authored
-
simonpj@microsoft.com authored
Before the coKindFun could be applied to too many arguments; now it expects exactly the right number of arguments. That makes it easier to write the coKindFuns, and localises the work.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Linear implicit parameters have been in GHC quite a while, but we decided they were a mis-feature and scheduled them for removal. This patch does the job.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
Simon Marlow authored
-
- 28 Sep, 2006 5 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
Without jumping to line numbers or %-expansion, we could add that later.
-
Simon Marlow authored
-
Simon Marlow authored
-