summaryrefslogtreecommitdiff
path: root/compiler/codeGen/ClosureInfo.lhs
Commit message (Collapse)AuthorAgeFilesLines
* Support code generation for unboxed-tuple function argumentsunboxed-tuple-arguments2Max Bolingbroke2012-05-151-15/+20
| | | | | | | | | | | This is done by a 'unarisation' pre-pass at the STG level which translates away all (live) binders binding something of unboxed tuple type. This has the following knock-on effects: * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind) * Various relaxed type checks in typechecker, 'foreign import prim' etc * All case binders may be live at the Core level
* Add support for type-level "strings".Iavor S. Diatchki2012-01-241-1/+2
| | | | | | | | | | | | These are types that look like "this" and "that". They are of kind `Symbol`, defined in module `GHC.TypeLits`. For each type-level symbol `X`, we have a singleton type, `TSymbol X`. The value of the singleton type can be named with the overloaded constant `tSymbol`. Here is an example: tSymbol :: TSymbol "Hello"
* Mainly, rename LiteralTy to LitTySimon Peyton Jones2012-01-131-1/+1
|
* Merge remote-tracking branch 'origin/master' into type-natsIavor S. Diatchki2012-01-071-7/+5
|\
| * Fixup to 4464c92badaedc45ce53d6349f6790f6d2298103Simon Marlow2012-01-051-1/+4
| | | | | | | | | | | | | | | | Instead of enterLocalIdLabel we should get the label from the ClosureInfo, because that knows better whether the label should be local or not. Needed by #5357
| * remove dead codeSimon Marlow2012-01-041-6/+1
| |
* | Extend GHC's type with a representation for type level literals.Iavor S. Diatchki2011-12-181-0/+7
|/ | | | | Currently, we support only numeric literals but---hopefully---these modifications should make it fairly easy to add other ones, if necessary.
* Use -fwarn-tabs when validatingIan Lynagh2011-11-041-0/+7
| | | | | We only use it for "compiler" sources, i.e. not for libraries. Many modules have a -fno-warn-tabs kludge for now.
* Implement -XConstraintKindMax Bolingbroke2011-09-061-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact, this patch adds a new kind Constraint such that: Show :: * -> Constraint (?x::Int) :: Constraint (Int ~ a) :: Constraint And you can write *any* type with kind Constraint to the left of (=>): even if that type is a type synonym, type variable, indexed type or so on. The following (somewhat related) changes are also made: 1. We now box equality evidence. This is required because we want to give (Int ~ a) the *lifted* kind Constraint 2. For similar reasons, implicit parameters can now only be of a lifted kind. (?x::Int#) => ty is now ruled out 3. Implicit parameter constraints are now allowed in superclasses and instance contexts (this just falls out as OK with the new constraint solver) Internally the following major changes were made: 1. There is now no PredTy in the Type data type. Instead GHC checks the kind of a type to figure out if it is a predicate 2. There is now no AClass TyThing: we represent classes as TyThings just as a ATyCon (classes had TyCons anyway) 3. What used to be (~) is now pretty-printed as (~#). The box constructor EqBox :: (a ~# b) -> (a ~ b) 4. The type LCoercion is used internally in the constraint solver and type checker to represent coercions with free variables of type (a ~ b) rather than (a ~# b)
* fix the eager-blackholing check, which I inadvertently broke inSimon Marlow2011-09-061-33/+4
| | | | | 1c2f89535394958f75cfb15c8c5e0433a20953ed (symptom was broken biographical profiling, see #5451).
* fix warningSimon Marlow2011-08-251-1/+1
|
* refactoring and fixing the stage 2 compilationSimon Marlow2011-08-251-19/+32
|
* More refactoring (CgRep)Simon Peyton Jones2011-08-251-0/+154
| | | | | | * Move CgRep (private to old codgen) from SMRep to ClosureInfo * Avoid using CgRep in new codegen * Move SMRep and Bitmap from codeGen/ to cmm/
* Snapshot of codegen refactoring to share with simonpjSimon Marlow2011-08-251-142/+32
|
* Add Type.tyConAppTyCon_maybe and tyConAppArgs_maybe, and use themSimon Peyton Jones2011-08-031-3/+3
| | | | | | These turn out to be a useful special case of splitTyConApp_maybe. A refactoring only; no change in behaviour
* Eliminate localiseLabelMax Bolingbroke2011-07-281-5/+4
|
* Eliminate infoLblToEntryLblMax Bolingbroke2011-07-281-15/+23
|
* There is only one flavour of LFBlackHole: make that explicitMax Bolingbroke2011-07-281-7/+6
|
* Put the info CLabel in CmmInfoTable rather than a localness flag, tidy up ↵Max Bolingbroke2011-07-281-8/+8
| | | | some info<->entry conversions
* Repair sanity of infoTableLabelFromCI in old code generatorMax Bolingbroke2011-07-281-14/+19
|
* Don't export the _info symbol for the data constructor worker bindingsMax Bolingbroke2011-07-071-6/+16
| | | | | | | This is safe because GHC never generates a fast call to a data constructor worker: if the call is seen statically it will be eta-expanded and the allocation of the data will be inlined. We still need to export the _closure in case the constructor is used in an unapplied fashion.
* Fix Trac #5286: getPredTyDescriptionSimon Peyton Jones2011-06-301-1/+1
|
* Never jump directly to a thunk's entry code, even if it is single-entrySimon Marlow2010-03-251-10/+18
| | | | | | I don't think this fixes any bugs as we don't have single-entry thunks at the moment, but it could cause problems for parallel execution if we ever did re-introduce update avoidance.
* Trim unused imports detected by new unused-import codesimonpj@microsoft.com2009-07-061-1/+0
|
* FIX biographical profiling (#3039, probably #2297)Simon Marlow2009-03-171-0/+4
| | | | | | | | | Since we introduced pointer tagging, we no longer always enter a closure to evaluate it. However, the biographical profiler relies on closures being entered in order to mark them as "used", so we were getting spurious amounts of data attributed to VOID. It turns out there are various places that need to be fixed, and I think at least one of them was also wrong before pointer tagging (CgCon.cgReturnDataCon).
* Make the ASSERT more informativesimonpj@microsoft.com2009-01-131-1/+1
|
* Fix warnings in ClosureInfoIan Lynagh2008-12-291-34/+43
|
* Use DynFlags to work out if we are doing ticky ticky profilingIan Lynagh2008-12-181-15/+17
| | | | We used to use StaticFlags
* Comments only (Note [Entering error thunks])simonpj@microsoft.com2008-12-051-0/+24
|
* Merging in the new codegen branchdias@eecs.harvard.edu2008-08-141-25/+27
| | | | | | | | | | | | | | | | | | This merge does not turn on the new codegen (which only compiles a select few programs at this point), but it does introduce some changes to the old code generator. The high bits: 1. The Rep Swamp patch is finally here. The highlight is that the representation of types at the machine level has changed. Consequently, this patch contains updates across several back ends. 2. The new Stg -> Cmm path is here, although it appears to have a fair number of bugs lurking. 3. Many improvements along the CmmCPSZ path, including: o stack layout o some code for infotables, half of which is right and half wrong o proc-point splitting
* Add optional eager black-holing, with new flag -feager-blackholingSimon Marlow2008-11-181-11/+1
| | | | | | | | | | | | | | | Eager blackholing can improve parallel performance by reducing the chances that two threads perform the same computation. However, it has a cost: one extra memory write per thunk entry. To get the best results, any code which may be executed in parallel should be compiled with eager blackholing turned on. But since there's a cost for sequential code, we make it optional and turn it on for the parallel package only. It might be a good idea to compile applications (or modules) with parallel code in with -feager-blackholing. ToDo: document -feager-blackholing.
* Replace ASSERT with WARN, and explain whysimonpj@microsoft.com2008-09-181-3/+30
| | | | | | | The DPH library tripped an ASSERT. The code is actually OK, but it's badly-optimised so I changed it to WARN. The issue here is explained in ClosureInfo, Note [Unsafe coerce complications].
* Fix Haddock errors.Thomas Schilling2008-07-201-1/+2
|
* (F)SLIT -> (f)sLit in ClosureInfoIan Lynagh2008-04-121-1/+1
|
* Remove leftover NoteTy/FTVNote bitsIan Lynagh2008-03-151-1/+0
|
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+7
|
* Change the strategy to determine dynamic data accessClemens Fruhwirth2007-07-311-31/+26
| | | | | | | | | | | | | Instead of attaching the information whether a Label is going to be accessed dynamically or not (distinction between IdLabel/DynLabel and additional flags in ModuleInitLabel and PlainModuleInitLabel), we hand dflags through the CmmOpt monad and the NatM monad. Before calling labelDynamic in PositionIndependentCode, we extract thisPackage from dflags and supply the current package to labelDynamic, so it can take this information into account instead of extracting it from the labels itself. This simplifies a lot of code in codeGen that just hands through this_pkg.
* Pointer TaggingSimon Marlow2007-07-271-5/+33
| | | | | | | | | | | | | | | | | | | | | | This patch implements pointer tagging as per our ICFP'07 paper "Faster laziness using dynamic pointer tagging". It improves performance by 10-15% for most workloads, including GHC itself. The original patches were by Alexey Rodriguez Yakushev <mrchebas@gmail.com>, with additions and improvements by me. I've re-recorded the development as a single patch. The basic idea is this: we use the low 2 bits of a pointer to a heap object (3 bits on a 64-bit architecture) to encode some information about the object pointed to. For a constructor, we encode the "tag" of the constructor (e.g. True vs. False), for a function closure its arity. This enables some decisions to be made without dereferencing the pointer, which speeds up some common operations. In particular it enables us to avoid costly indirect jumps in many cases. More information in the commentary: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging
* Multiple improvements to CPS algorithm.Michael D. Adams2007-07-021-0/+1
| | | | | | | | | | | | | | | These include: - Stack size detection now includes function arguments. - Stack size detection now avoids stack checks just because of the GC block. - A CmmCall followed by a CmmBranch will no longer generate an extra continuation consisting just of the brach. - Multiple CmmCall/CmmBranch pairs that all go to the same place will try to use the same continuation. If they can't (because the return value signature is different), adaptor block are built. - Function entry statements are now in a separate block. (Fixed bug with branches to the entry block having unintended effects.) - Other changes that I can't recall right now.
* Implemented and fixed bugs in CmmInfo handlingMichael D. Adams2007-06-271-5/+4
|
* Added an SRT to each CmmCall and added the current SRT to the CgMonadMichael D. Adams2007-06-271-0/+4
|
* Remove bogus assertion in getCallMethodKirsten Chevalier2007-01-111-1/+7
| | | | | | | | | | | With my as-yet-uncommitted changes to the demand analyzer, code got generated for some programs that caused this assertion to fail. The transformation I was doing was correct; it was the assertion that wasn't. So, the assertion is removed. This is actually Simon PJ's patch rather than mine, but I noticed that it wasn't checked in and it seems completely safe to do so.
* Add the primitive type Any, and use it for Dynamicssimonpj@microsoft.com2006-10-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC's code generator can only enter a closure if it's guaranteed not to be a function. In the Dynamic module, we were using the type (forall a.a) as the type to which the dynamic type was unsafely cast: type Obj = forall a.a Gut alas this polytype was sometimes instantiated to (), something like this (it only bit when profiling was enabled) let y::() = dyn () in (y `cast` ..) p q As a result, an ASSERT in ClosureInfo fired (hooray). I've tided this up by making a new, primitive, lifted type Any, and arranging that Dynamic uses Any, thus: type Obj = ANy While I was at it, I also arranged that when the type checker instantiates un-constrained type variables, it now instantiates them to Any, not () e.g. length Any [] [There remains a Horrible Hack when we want Any-like things at arbitrary kinds. This essentially never happens, but see comments with TysPrim.mkAnyPrimTyCon.] Anyway, this fixes Trac #905
* Comments onlsimonpj@microsoft.com2006-10-181-3/+4
|
* Module header tidyup, phase 1Simon Marlow2006-10-111-15/+14
| | | | | | | | | | | | This patch is a start on removing import lists and generally tidying up the top of each module. In addition to removing import lists: - Change DATA.IOREF -> Data.IORef etc. - Change List -> Data.List etc. - Remove $Id$ - Update copyrights - Re-order imports to put non-GHC imports last - Remove some unused and duplicate imports
* Generalise Package SupportSimon Marlow2006-07-251-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch pushes through one fundamental change: a module is now identified by the pair of its package and module name, whereas previously it was identified by its module name alone. This means that now a program can contain multiple modules with the same name, as long as they belong to different packages. This is a language change - the Haskell report says nothing about packages, but it is now necessary to understand packages in order to understand GHC's module system. For example, a type T from module M in package P is different from a type T from module M in package Q. Previously this wasn't an issue because there could only be a single module M in the program. The "module restriction" on combining packages has therefore been lifted, and a program can contain multiple versions of the same package. Note that none of the proposed syntax changes have yet been implemented, but the architecture is geared towards supporting import declarations qualified by package name, and that is probably the next step. It is now necessary to specify the package name when compiling a package, using the -package-name flag (which has been un-deprecated). Fortunately Cabal still uses -package-name. Certain packages are "wired in". Currently the wired-in packages are: base, haskell98, template-haskell and rts, and are always referred to by these versionless names. Other packages are referred to with full package IDs (eg. "network-1.0"). This is because the compiler needs to refer to entities in the wired-in packages, and we didn't want to bake the version of these packages into the comiler. It's conceivable that someone might want to upgrade the base package independently of GHC. Internal changes: - There are two module-related types: ModuleName just a FastString, the name of a module Module a pair of a PackageId and ModuleName A mapping from ModuleName can be a UniqFM, but a mapping from Module must be a FiniteMap (we provide it as ModuleEnv). - The "HomeModules" type that was passed around the compiler is now gone, replaced in most cases by the current package name which is contained in DynFlags. We can tell whether a Module comes from the current package by comparing its package name against the current package. - While I was here, I changed PrintUnqual to be a little more useful: it now returns the ModuleName that the identifier should be qualified with according to the current scope, rather than its original module. Also, PrintUnqual tells whether to qualify module names with package names (currently unused). Docs to follow.
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+951
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.