- 19 Dec, 2012 14 commits
-
-
mad.one@gmail.com authored
There's only a single compiler backend now, so the 'z' suffix means nothing. Also, the flags were confusingly named ('cmm-foo' vs 'foo-cmm',) and counter-intuitively, '-ddump-cmm' did not do at all what you expected since the new backend went live. Basically, all of the -ddump-cmmz-* flags are now -ddump-cmm-*. Some were renamed to be more consistent. This doesn't update the manual; it already mentions '-ddump-cmm' and that flag implies all the others anyway, which is probably what you want. Signed-off-by:
Austin Seipp <mad.one@gmail.com>
-
-
Simon Peyton Jones authored
This fixes Trac #7368. The problem was that we were matching Bad w ~ f (Bad f) where (f :: * -> *). Thta leads to (w ~ Bad f), which is ill-kinded, but matchExpectedTyConApp was returning the (Bad f) as the argument type, and that was being used to instanatiate w in the data constructor type, which is very bad. The code also becomes simpler and easier to understand, which is an excellent thing.
-
Simon Peyton Jones authored
This fixes Trac #7503.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
They properly belong in TysWiredIn, since they are defined in Haskell in GHC.TypeLits. Moveover, make them WiredIn (again as they should be) and use checkWiredInTyCon when encountering them in TcHsType.tc_hs_type, so that the interface file is loaded. This fixes Trac #7502.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
-
Gabor Greif authored
-
Gabor Greif authored
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
Nothing big here, just tidying up deetails
-
Simon Peyton Jones authored
-
Iavor S. Diatchki authored
-
- 18 Dec, 2012 2 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
This reverts commit f184d9ca. The next commit will fix it in a better way.
-
- 16 Dec, 2012 1 commit
-
-
ian@well-typed.com authored
-
- 15 Dec, 2012 3 commits
-
-
Erik de Castro Lopo authored
Fixes #7498.
-
Erik de Castro Lopo authored
-
Erik de Castro Lopo authored
On x86 and powerpc, the second form above was ignoring all the CPP lines and hence trying to compile x86 asm on powerpc and powerpc asm on x86.
-
- 14 Dec, 2012 10 commits
-
-
ian@well-typed.com authored
I'm not sure if making an entirely new HscEnv is too large a hammer, but it works for now.
-
ian@well-typed.com authored
-
ian@well-typed.com authored
-
ian@well-typed.com authored
-
Simon Peyton Jones authored
Conflicts: compiler/typecheck/TcTyClsDecls.lhs
-
Simon Peyton Jones authored
The situation was pretty dire. The way in which data constructors were handled, notably the mapping between their *source* argument types and their *representation* argument types (after seq'ing and unpacking) was scattered in three different places, and hard to keep in sync. Now it is all in one place: * The dcRep field of a DataCon gives its representation, specified by a DataConRep * As well as having the wrapper, the DataConRep has a "boxer" of type DataConBoxer (defined in MkId for loopy reasons). The boxer used at a pattern match to reconstruct the source-level arguments from the rep-level bindings in the pattern match. * The unboxing in the wrapper and the boxing in the boxer are dual, and are now constructed together, by MkId.mkDataConRep. This is the key function of this change. * All the computeBoxingStrategy code in TcTyClsDcls disappears. Much nicer. There is a little bit of refactoring left to do; the strange deepSplitProductType functions are now called only in WwLib, so I moved them there, and I think they could be tidied up further.
-
ian@well-typed.com authored
-
ian@well-typed.com authored
-
ian@well-typed.com authored
-
ian@well-typed.com authored
Working towards removing FastBytes
-
- 13 Dec, 2012 7 commits
-
-
ian@well-typed.com authored
-
Simon Marlow authored
-
Simon Marlow authored
it was only needed for registerised compilation.
-
ian@well-typed.com authored
-
ian@well-typed.com authored
-
tibbe authored
-
ian@well-typed.com authored
A step on the way to getting rid of FastBytes slow nofib Compile times look like: -1 s.d. -2.4% +1 s.d. +3.4% Average +0.4% but looking at the times for the longer-running compilations I think the change is just noise.
-
- 12 Dec, 2012 3 commits
-
-
ian@well-typed.com authored
-
ian@well-typed.com authored
Slow nofib Compile Times difference looks like just noise: -1 s.d. -2.9% +1 s.d. +2.9% Average -0.1%
-
ian@well-typed.com authored
-