summaryrefslogtreecommitdiff
path: root/compiler/vectorise
diff options
context:
space:
mode:
authorEdward Z. Yang <ezyang@cs.stanford.edu>2016-06-24 11:03:47 -0700
committerEdward Z. Yang <ezyang@cs.stanford.edu>2016-06-30 10:43:28 -0700
commitb8b3e30a6eedf9f213b8a718573c4827cfa230ba (patch)
treecc8f8394fbf92afa12a5aa0bcc0e664d4f841efb /compiler/vectorise
parent480e0661fb45395610d6b4a7c586a580d30d8df4 (diff)
downloadhaskell-b8b3e30a6eedf9f213b8a718573c4827cfa230ba.tar.gz
Axe RecFlag on TyCons.
Summary: This commit removes the information about whether or not a TyCon is "recursive", as well as the code responsible for calculating this information. The original trigger for this change was complexity regarding how we computed the RecFlag for hs-boot files. The problem is that in order to determine if a TyCon is recursive or not, we need to determine if it was defined in an hs-boot file (if so, we conservatively assume that it is recursive.) It turns that doing this is quite tricky. The "obvious" strategy is to typecheck the hi-boot file (since we are eventually going to need the typechecked types to check if we properly implemented the hi-boot file) and just extract the names of all defined TyCons from the ModDetails, but this actually does not work well if Names from the hi-boot file are being knot-tied via if_rec_types: the "extraction" process will force thunks, which will force the typechecking process earlier than we have actually defined the types locally. Rather than work around all this trickiness (it certainly can be worked around, either by making interface loading MORE lazy, or just reading of the set of defined TyCons directly from the ModIface), we instead opted to excise the source of the problem, the RecFlag. For one, it is not clear if the RecFlag even makes sense, in the presence of higher-orderness: data T f a = MkT (f a) T doesn't look recursive, but if we instantiate f with T, then it very well is! It was all very shaky. So we just don't bother anymore. This has two user-visible implications: 1. is_too_recursive now assumes that all TyCons are recursive and will bail out in a way that is still mysterious to me if there are too many TyCons. 2. checkRecTc, which is used when stripping newtypes to get to representation, also assumes all TyCons are recursive, and will stop running if we hit the limit. The biggest risk for this patch is that we specialize less than we used to; however, the codeGen tests still seem to be passing. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewers: simonpj, austin, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2360
Diffstat (limited to 'compiler/vectorise')
-rw-r--r--compiler/vectorise/Vectorise/Generic/PData.hs3
-rw-r--r--compiler/vectorise/Vectorise/Type/TyConDecl.hs11
2 files changed, 2 insertions, 12 deletions
diff --git a/compiler/vectorise/Vectorise/Generic/PData.hs b/compiler/vectorise/Vectorise/Generic/PData.hs
index 9fbe1283f2..d4abeae51b 100644
--- a/compiler/vectorise/Vectorise/Generic/PData.hs
+++ b/compiler/vectorise/Vectorise/Generic/PData.hs
@@ -14,7 +14,6 @@ import Vectorise.Generic.Description
import Vectorise.Utils
import Vectorise.Env( GlobalEnv( global_fam_inst_env ) )
-import BasicTypes
import BuildTyCl
import DataCon
import TyCon
@@ -58,12 +57,10 @@ buildDataFamInst name' fam_tc vect_tc rhs
[] -- no stupid theta
rhs
(DataFamInstTyCon ax fam_tc pat_tys)
- rec_flag -- FIXME: is this ok?
False -- not GADT syntax
; liftDs $ newFamInst (DataFamilyInst rep_tc) ax }
where
tyvars = tyConTyVars vect_tc
- rec_flag = boolToRecFlag (isRecursiveTyCon vect_tc)
buildPDataTyConRhs :: Name -> TyCon -> TyCon -> SumRepr -> VM AlgTyConRhs
buildPDataTyConRhs orig_name vect_tc repr_tc repr
diff --git a/compiler/vectorise/Vectorise/Type/TyConDecl.hs b/compiler/vectorise/Vectorise/Type/TyConDecl.hs
index 3085beb183..a75391eca5 100644
--- a/compiler/vectorise/Vectorise/Type/TyConDecl.hs
+++ b/compiler/vectorise/Vectorise/Type/TyConDecl.hs
@@ -12,7 +12,6 @@ import Class
import Type
import TyCon
import DataCon
-import BasicTypes
import DynFlags
import Var
import Name
@@ -51,9 +50,6 @@ vectTyConDecl tycon name'
opTys = drop (length argTys - length opItems) argTys -- only method types
; methods' <- sequence [ vectMethod id meth ty | ((id, meth), ty) <- zip opItems opTys]
- -- keep the original recursiveness flag
- ; let rec_flag = boolToRecFlag (isRecursiveTyCon tycon)
-
-- construct the vectorised class (this also creates the class type constructors and its
-- data constructor)
--
@@ -68,7 +64,6 @@ vectTyConDecl tycon name'
[] -- no associated types (for the moment)
methods' -- method info
(classMinimalDef cls) -- Inherit minimal complete definition from cls
- rec_flag -- whether recursive
-- the original dictionary constructor must map to the vectorised one
; let tycon' = classTyCon cls'
@@ -94,9 +89,8 @@ vectTyConDecl tycon name'
-- vectorise the data constructor of the class tycon
; rhs' <- vectAlgTyConRhs tycon (algTyConRhs tycon)
- -- keep the original recursiveness and GADT flags
- ; let rec_flag = boolToRecFlag (isRecursiveTyCon tycon)
- gadt_flag = isGadtSyntaxTyCon tycon
+ -- keep the original GADT flags
+ ; let gadt_flag = isGadtSyntaxTyCon tycon
-- build the vectorised type constructor
; tc_rep_name <- mkDerivedName mkTyConRepOcc name'
@@ -109,7 +103,6 @@ vectTyConDecl tycon name'
[] -- no stupid theta
rhs' -- new constructor defs
(VanillaAlgTyCon tc_rep_name)
- rec_flag -- whether recursive
gadt_flag -- whether in GADT syntax
}