summaryrefslogtreecommitdiff
path: root/utils/genapply
Commit message (Collapse)AuthorAgeFilesLines
...
* Use -fforce-recomp rather than -no-recomp when building genapplyIan Lynagh2008-06-141-1/+1
|
* 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.
* Fix and supress some warnings, and turn on -Werror when validatingIan Lynagh2007-09-021-0/+6
|
* annotate C-- calls that do not returnNorman Ramsey2007-08-201-1/+1
| | | | | | | | | * The correct definition of C-- requires that a procedure not 'fall off the end'. The 'never returns' annotation tells us if a (foreign) call is not going to return. Validated!
* Pointer TaggingSimon Marlow2007-07-271-12/+107
| | | | | | | | | | | | | | | | | | | | | | 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
* Implemented and fixed bugs in CmmInfo handlingMichael D. Adams2007-06-271-3/+14
|
* remove #if branches for pre-ghc-6.0Isaac Dupree2007-06-051-9/+0
| | | | | | I skipped utils/hsc2hs/Main.hs since its ifs also involved checking for old versions of nhc98 (I don't want to figure that out), but removed everything else I found relating to building with pre-6.0
* -package pretty is required for GHC >= 6.7Simon Marlow2007-05-251-0/+4
|
* Remove ghc_ge_504 (it's required to be true now anyway)Ian Lynagh2007-05-091-4/+0
|
* Lightweight ticky-ticky profilingKirsten Chevalier2007-02-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following changes restore ticky-ticky profiling to functionality from its formerly bit-rotted state. Sort of. (It got bit-rotted as part of the switch to the C-- back-end.) The way that ticky-ticky is supposed to work is documented in Section 5.7 of the GHC manual (though the manual doesn't mention that it hasn't worked since sometime around 6.0, alas). Changes from this are as follows (which I'll document on the wiki): * In the past, you had to build all of the libraries with way=t in order to use ticky-ticky, because it entailed a different closure layout. No longer. You still need to do make way=t in rts/ in order to build the ticky RTS, but you should now be able to mix ticky and non-ticky modules. * Some of the counters that worked in the past aren't implemented yet. I was originally just trying to get entry counts to work, so those should be correct. The list of counters was never documented in the first place, so I hope it's not too much of a disaster that some don't appear anymore. Someday, someone (perhaps me) should document all the counters and what they do. For now, all of the counters are either accurate (or at least as accurate as they always were), zero, or missing from the ticky profiling report altogether. This hasn't been particularly well-tested, but these changes shouldn't affect anything except when compiling with -fticky-ticky (famous last words...) Implementation details: I got rid of StgTicky.h, which in the past had the macros and declarations for all of the ticky counters. Now, those macros are defined in Cmm.h. StgTicky.h was still there for inclusion in C code. Now, any remaining C code simply cannot call the ticky macros -- or rather, they do call those macros, but from the perspective of C code, they're defined as no-ops. (This shouldn't be too big a problem.) I added a new file TickyCounter.h that has all the declarations for ticky counters, as well as dummy macros for use in C code. Someday, these declarations should really be automatically generated, since they need to be kept consistent with the macros defined in Cmm.h. Other changes include getting rid of the header that was getting added to closures before, and getting rid of various code having to do with eager blackholing and permanent indirections (the changes under compiler/ and rts/Updates.*).
* Support RelocatableReadOnlyData section type in CmmParse, and use it where ↵wolfgang.thaller@gmx.net2006-10-221-2/+2
| | | | | | | needed in AutoApply This is needed for position-independent code on Mac OS X (both i386 and powerpc), when compiling the RTS with -fasm.
* Cast switch scrutinees to W_ in AutoApply.cmmwolfgang.thaller@gmx.net2006-10-221-2/+2
| | | | | | ... and make CmmLint check for this problem. This doesn't matter for -fvia-C, but passing a halfword to a switch will make the NCG generate crashing code.
* Reorganisation of the source treeSimon Marlow2006-04-072-0/+794
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.