summaryrefslogtreecommitdiff
path: root/compiler/codeGen/CgPrimOp.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Merging in the new codegen branchdias@eecs.harvard.edu2008-08-141-159/+172
| | | | | | | | | | | | | | | | | | 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
* replace Cmm 'hint' with 'kind'Norman Ramsey2008-05-031-7/+7
| | | | | | C-- no longer has 'hints'; to guide parameter passing, it has 'kinds'. Renamed type constructor, data constructor, and record fields accordingly
* (F)SLIT -> (f)sLit in CgPrimOpIan Lynagh2008-04-121-3/+1
|
* Don't import FastString in HsVersions.hIan Lynagh2008-03-291-0/+1
| | | | Modules that need it import it themselves instead.
* change CmmActual, CmmFormal to use a data CmmHinted rather than tuple (#1405)Isaac Dupree2008-01-041-5/+7
| | | | | | | This allows the instance of UserOfLocalRegs to be within Haskell98, and IMHO makes the code a little cleaner generally. This is one small (though tedious) step towards making GHC's code more portable...
* Move OPTIONS pragmas above commentsIan Lynagh2007-09-211-7/+7
| | | | Fixes building with -Werror (i.e. validate) and GHC < 6.6
* a good deal of salutory renamingNorman Ramsey2007-09-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've renamed a number of type and data constructors within Cmm so that the names used in the compiler may more closely reflect the C-- specification 2.1. I've done a bit of other renaming as well. Highlights: CmmFormal and CmmActual now bear a CmmKind (which for now is a MachHint as before) CmmFormals = [CmmFormal] and CmmActuals = [CmmActual] suitable changes have been made to both code and nonterminals in the Cmm parser (which is as yet untested) For reasons I don't understand, parts of the code generator use a sequence of 'formal parameters' with no C-- kinds. For these we now have the types type CmmFormalWithoutKind = LocalReg type CmmFormalsWithoutKinds = [CmmFormalWithoutKind] A great many appearances of (Tau, MachHint) have been simplified to the appropriate CmmFormal or CmmActual, though I'm sure there are more opportunities. Kind and its data constructors are now renamed to data GCKind = GCKindPtr | GCKindNonPtr to avoid confusion with the Kind used in the type checker and with CmmKind. Finally, in a somewhat unrelated bit (and in honor of Simon PJ, who thought of the name), the Whalley/Davidson 'transaction limit' is now called 'OptimizationFuel' with the net effect that there are no longer two unrelated uses of the abbreviation 'tx'.
* 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
|
* put CmmReturnInfo into a CmmCall (and related types)Norman Ramsey2007-08-201-0/+3
|
* Rename a constructor CmmForeignCall to CmmCallee, and tidy Cmm codesimonpj@microsoft.com2007-08-091-2/+2
| | | | | | This patch should have no effect; it's mainly comments, layout, plus this contructor name change.
* Pointer TaggingSimon Marlow2007-07-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* Warning PoliceMichael D. Adams2007-07-051-3/+0
|
* Added an SRT to each CmmCall and added the current SRT to the CgMonadMichael D. Adams2007-06-271-0/+4
|
* Added pointerhood to LocalRegMichael D. Adams2007-06-271-23/+23
| | | | | | This version should compile but is still incomplete as it introduces potential bugs at the places marked 'TODO FIXME NOW'. It is being recorded to help keep track of changes.
* Module header tidyup, phase 1Simon Marlow2006-10-111-13/+12
| | | | | | | | | | | | 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
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+584
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.
View Lorry Controller Status