- 05 Dec, 2012 1 commit
-
-
chak@cse.unsw.edu.au. authored
* Vectorisation avoidance is now the default * Types and values from unvectorised modules are permitted in scalar code * Simplified the VECTORISE pragmas (see http://hackage.haskell.org/trac/ghc/wiki/DataParallel/VectPragma for the spec) * Vectorisation information is now included in the annotated Core AST
-
- 27 Jun, 2012 1 commit
-
-
chak@cse.unsw.edu.au. authored
-
- 12 Jun, 2012 1 commit
-
-
Ian Lynagh authored
-
- 05 Jun, 2012 1 commit
-
-
Ian Lynagh authored
By using Haskell's debugIsOn rather than CPP's "#ifdef DEBUG", we don't need to kludge things to keep the warning checker happy etc.
-
- 03 Jan, 2012 1 commit
-
-
Simon Peyton Jones authored
This patch should have no user-visible effect. It implements a significant internal refactoring of the way that FC axioms are handled. The ultimate goal is to put us in a position to implement "pattern-matching axioms". But the changes here are only does refactoring; there is no change in functionality. Specifically: * We now treat data/type family instance declarations very, very similarly to types class instance declarations: - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with FamInstEnv.FamInst. This change does affect the GHC API, but for the better I think. - Previously, each family type/data instance declaration gave rise to a *TyCon*; typechecking a type/data instance decl produced that TyCon. Now, each type/data instance gives rise to a *FamInst*, by direct analogy with each class instance declaration giving rise to a ClsInst. - Just as each ClsInst contains its evidence, a DFunId, so each FamInst contains its evidence, a CoAxiom. See Note [FamInsts and CoAxioms] in FamInstEnv. The CoAxiom is a System-FC thing, and can relate any two types, whereas the FamInst relates directly to the Haskell source language construct, and always has a function (F tys) on the LHS. - Just as a DFunId has its own declaration in an interface file, so now do CoAxioms (see IfaceSyn.IfaceAxiom). These changes give rise to almost all the refactoring. * We used to have a hack whereby a type family instance produced a dummy type synonym, thus type instance F Int = Bool -> Bool translated to axiom FInt :: F Int ~ R:FInt type R:FInt = Bool -> Bool This was always a hack, and now it's gone. Instead the type instance declaration produces a FamInst, whose axiom has kind axiom FInt :: F Int ~ Bool -> Bool just as you'd expect. * Newtypes are done just as before; they generate a CoAxiom. These CoAxioms are "implicit" (do not generate an IfaceAxiom declaration), unlike the ones coming from family instance declarations. See Note [Implicit axioms] in TyCon On the whole the code gets significantly nicer. There were consequential tidy-ups in the vectoriser, but I think I got them right.
-
- 31 Oct, 2011 1 commit
-
-
chak@cse.unsw.edu.au. authored
* Frontend support (not yet used in the vectoriser)
-
- 10 Sep, 2011 1 commit
-
-
chak@cse.unsw.edu.au. authored
- Toplevel bindings that cannot be vectorised are reported as a warning - '-ddump-vt-trace' has even more information about unvectorised code - Fixed some documentation
-
- 18 Jun, 2011 1 commit
-
-
dterei authored
OverlappingInstances in Safe modules can only overlap instances defined in the same module.
-
- 13 Sep, 2010 1 commit
-
-
simonpj@microsoft.com authored
This major patch implements the new OutsideIn constraint solving algorithm in the typecheker, following our JFP paper "Modular type inference with local assumptions". Done with major help from Dimitrios Vytiniotis and Brent Yorgey.
-
- 31 Aug, 2010 1 commit
-
-
benl@ouroborus.net authored
-