summaryrefslogtreecommitdiff
path: root/compiler/codeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Adding pushing of hpc translation status through hi files.andy@galois.com2007-07-172-2/+2
| | | | | | | | | | Now, if a single module *anywhere* on the module tree is built with -fhpc, the binary will enable reading/writing of <bin>.tix. Previously, you needed to compile Main to allow coverage to operate. This changes the file format for .hi files; you will need to recompile every library.
* Adding support for package names into hpc outputed codeandy@galois.com2007-07-111-3/+7
| | | | | | | | | | | | | | We store .mix files in .hpc/<package>/<the.module.name>.mix The package main the empty package (aka other naming passes), so Main just is stored in .hpc/Main.tix This change in backwards compatable.
* Ensure no statements after CmmReturn are emittedMichael D. Adams2007-07-051-0/+1
|
* Warning PoliceMichael D. Adams2007-07-051-3/+0
|
* Remove mapAccumL, mapAccumR, mapAccumBIan Lynagh2007-07-023-0/+5
| | | | | mapAccumL and mapAccumR are in Data.List now. mapAccumB is unused.
* Added support for update frames to the CPS passMichael D. Adams2007-07-032-6/+8
| | | | (This required a bit of refactoring of CmmInfo.)
* 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.
* Fix typo from amend-recordMichael D. Adams2007-06-271-1/+1
|
* Implemented and fixed bugs in CmmInfo handlingMichael D. Adams2007-06-278-281/+236
|
* Added stack checks to the CPS algorithmMichael D. Adams2007-06-271-1/+1
| | | | | | | | | | | | This eliminates one of the panics introduced by the previous patch: 'First pass at implementing info tables for CPS' The other panic introduced by that patch still remains. It was due to the need to convert from a ContinuationInfo to a CmmInfo. (codeGen/CgInfoTbls.hs:emitClosureCodeAndInfoTable) (codeGen/CgInfoTbls.hs:emitReturnTarget)
* First pass at implementing info tables for CPSMichael D. Adams2007-06-275-13/+45
| | | | | | | | | | | | | | | | This is a fairly complete implementation, however two 'panic's have been placed in the critical path where the implementation is still a bit lacking so do not expect it to run quite yet. One call to panic is because we still need to create a GC block for procedures that don't have them yet. (cmm/CmmCPS.hs:continuationToProc) The other is due to the need to convert from a ContinuationInfo to a CmmInfo. (codeGen/CgInfoTbls.hs:emitClosureCodeAndInfoTable) (codeGen/CgInfoTbls.hs:emitReturnTarget)
* Added an SRT to each CmmCall and added the current SRT to the CgMonadMichael D. Adams2007-06-2712-79/+117
|
* Added pointerhood to LocalRegMichael D. Adams2007-06-2710-117/+148
| | | | | | 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.
* Fix bug relating to the return values of prim opsMichael D. Adams2007-06-261-1/+1
| | | | | | The return values were getting put in a LocalReg but that LocalReg needed to be stored into the enclosing expression's return register (e.g. R1).
* Removed trailing whitespaceMichael D. Adams2007-06-211-1/+1
|
* Fixed typo in commentMichael D. Adams2007-06-191-1/+1
|
* Moved global register saving from the backend to codeGenMichael D. Adams2007-05-252-6/+25
| | | | | | | | | | | | | | | | | This frees the Cmm data type from keeping a list of live global registers in CmmCall which helps prepare for the CPS conversion phase. CPS conversion does its own liveness analysis and takes input that should not directly refer to parameter registers (e.g. R1, F5, D3, L2). Since these are the only things which could occur in the live global register list, CPS conversion makes that field of the CmmCall constructor obsolite. Once the CPS conversion pass is fully implemented, global register saving will move from codeGen into the CPS pass. Until then, this patch is worth scrutinizing and testing to ensure it doesn't cause any performance or correctness problems as the code passed to the backends by the CPS converting will look very similar to the code that this patch makes codeGen pass to the backend.
* Make CmmProc take CmmFormals as argumentMichael D. Adams2007-05-222-3/+3
| | | | | | | | | | | | | Since a CmmCall returns CmmFormals which may include global registers (and indeed one place in the code returns the results of a CmmCall into BaseReg) and since CPS conversion will change those return slots into formal arguments for the continuation of the call, CmmProc has to have CmmFormals for the formal arguments. Oddly, the old code never made use of procedure arguments so this change only effects the types and not any of the code. (Because [] is both of type [LocalReg] and CmmFormals.)
* Fixed a documentation errorMichael D. Adams2007-06-081-2/+2
|
* removing -fhpc-tracer from ghc, is subsumed by the GHC debuggerandy@galois.com2007-06-221-26/+0
|
* FIX #1418 (partially)Simon Marlow2007-06-131-2/+4
| | | | | | | | | | | | | When the con_desc field of an info table was made into a relative reference, this had the side effect of making the profiling fields (closure_desc and closure_type) also relative, but only when compiling via C, and the heap profiler was still treating them as absolute, leading to crashes when profiling with -hd or -hy. This patch fixes up the story to be consistent: these fields really should be relative (otherwise we couldn't make shared versions of the profiling libraries), so I've made them relative and fixed up the RTS to know about this.
* Removed defunct compiler/codeGen/CgUsages.hi-boot-6Michael D. Adams2007-05-251-3/+0
|
* Keep flattenCgStmts from emitting spurious 'goto' after CmmSwitchMichael D. Adams2007-05-211-0/+1
|
* Store a SrcSpan instead of a SrcLoc inside a NameSimon Marlow2007-05-111-1/+1
| | | | This has been a long-standing ToDo.
* Warning fix for unused and redundant importsMichael D. Adams2007-05-102-9/+0
|
* Store the constructor name in the info table in UTF-8Simon Marlow2007-05-092-3/+10
|
* Changing internal data structures used by Hpcandy@galois.com2007-04-301-5/+6
| | | | | | | | | - .tix files are now a list of MixModule, which contain a hash of the contents of the .mix file. - .mix files now have (the same) hash number. This changes allow different binaries that use the same module compiled in the same way to share coverage information.
* add the constructor name field to the info table for RTS constructorsSimon Marlow2007-04-271-1/+1
|
* Make ticky work, at least partly, on 64-bit machinessimonpj@microsoft.com2007-04-241-9/+10
| | | | | | | | | | | | | | The ticky StgEntCounter structure was trying to be clever by using a fixed-width 32-bit field for the registeredp value. But the code generators are not up to handling structures packed tightly like this (on a 64-bit architecture); result seg-fault on 64-bit. Really there should be some complaint from the code generators, not simply a seg fault. Anyway I switched to using native words for StgEntCounter fields, and now at least it works.
* Make constructor names in info tables position independentwolfgang.thaller@gmx.net2007-03-081-1/+2
| | | | | | | | | | Info tables, like everything else in the text section, MUST NOT contain pointers. A pointer is, by definition, position dependent and is therefore fundamentally incompatible with generating position independent code. Therefore, we have to store an offset from the info label to the string instead of the pointer, just as we already did for other things referred to by the info table (SRTs, large bitmaps, etc.)
* Remove vectored returns.Simon Marlow2007-02-289-245/+50
| | | | | We recently discovered that they aren't a win any more, and just cost code size.
* Constructor names in info tablesbjpop@csse.unimelb.edu.au2007-02-201-6/+15
| | | | | | | This patch adds data constructor names into their info tables. This is useful in the ghci debugger. It replaces the old scheme which was based on tracking data con names in the linker.
* Lightweight ticky-ticky profilingKirsten Chevalier2007-02-073-48/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.*).
* Semi-tagging optimisationSimon Marlow2007-01-225-96/+17
| | | | | | In the generated code for case-of-variable, test the tag of the scrutinee closure and only enter if it is unevaluated. Also turn *off* vectored returns.
* Semi-tagging optimisationSimon Marlow2007-01-225-17/+96
| | | | | | In the generated code for case-of-variable, test the tag of the scrutinee closure and only enter if it is unevaluated. Also turn *off* vectored returns.
* small debugging output cleanupmrchebas@gmail.com2007-01-191-4/+5
|
* don't make jump tables for small switches (<= 4 branches)mrchebas@gmail.com2007-01-191-3/+5
| | | | Only affects -fasm: gcc makes its own decisions about jump tables
* 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.
* Misc Hpc improvement to dynamic tracer outputandy@galois.com2006-12-131-1/+5
| | | | | | | - Added HPCRIX support for passing tracer filename. - Added thread tracing support. - Cleaned up use of HsFFI.h
* Adding tracing supportandy@galois.com2006-12-092-6/+32
|
* Layout and comments onlysimonpj@microsoft.com2006-11-071-4/+1
|
* fixing type error inside Hpc inc; we had a 32 bit '1'.andy@galois.com2006-10-251-1/+1
|
* Haskell Program Coverageandy@galois.com2006-10-243-16/+119
| | | | | | | | | | | | | | | | | | | | This large checkin is the new ghc version of Haskell Program Coverage, an expression-level coverage tool for Haskell. Parts: - Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files. - Coverage.lhs - Annotates the HsSyn with coverage tickboxes. - New Note's in Core, - TickBox -- ticked on entry to sub-expression - BinaryTickBox -- ticked on exit to sub-expression, depending -- on the boolean result. - New Stg level TickBox (no BinaryTickBoxes, though) You can run the coverage tool with -fhpc at compile time. Main must be compiled with -fhpc.
* 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
|
* Rejig TABLES_NEXT_TO_CODE: the -unreg flag was broken by earlier changesSimon Marlow2006-10-172-17/+7
| | | | | | | | A GHC binary can generally build either registerised or unregisterised code, unless it is unregisterised only. The previous changes broke this, but I think I've now restored it.
* Partially fix GHCi when unregisterisedIan Lynagh2006-10-121-1/+1
| | | | | | | | We were constructing info tables designed for TABLES_NEXT_TO_CODE, but were building without TABLES_NEXT_TO_CODE. This patch also fixes a bug when we are unregisterised on amd64 and have code with an address above 2^32.
* Module header tidyup, phase 1Simon Marlow2006-10-1122-453/+360
| | | | | | | | | | | | 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
* Interface file optimisation and removal of nameParentSimon Marlow2006-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This large commit combines several interrelated changes: - IfaceSyn now contains actual Names rather than the special IfaceExtName type. The binary interface file contains a symbol table of Names, where each entry is a (package, ModuleName, OccName) triple. Names in the IfaceSyn point to entries in the symbol table. This reduces the size of interface files, which should hopefully improve performance (not measured yet). The toIfaceXXX functions now do not need to pass around a function from Name -> IfaceExtName, which makes that code simpler. - Names now do not point directly to their parents, and the nameParent operation has gone away. It turned out to be hard to keep this information consistent in practice, and the parent info was only valid in some Names. Instead we made the following changes: * ImportAvails contains a new field imp_parent :: NameEnv AvailInfo which gives the family info for any Name in scope, and is used by the renamer when renaming export lists, amongst other things. This info is thrown away after renaming. * The mi_ver_fn field of ModIface now maps to (OccName,Version) instead of just Version, where the OccName is the parent name. This mapping is used when constructing the usage info for dependent modules. There may be entries in mi_ver_fn for things that are not in scope, whereas imp_parent only deals with in-scope things. * The md_exports field of ModDetails now contains [AvailInfo] rather than NameSet. This gives us family info for the exported names of a module. Also: - ifaceDeclSubBinders moved to IfaceSyn (seems like the right place for it). - heavily refactored renaming of import/export lists. - Unfortunately external core is now broken, as it relied on IfaceSyn. It requires some attention.
* GADT selector bugfix, bits of cleanupManuel M T Chakravarty2006-09-201-2/+2
| | | | | | | | Mon Sep 18 16:48:32 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * GADT selector bugfix, bits of cleanup Sun Aug 6 19:43:47 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * GADT selector bugfix, bits of cleanup Thu Jul 27 08:10:58 EDT 2006 kevind@bu.edu
View Lorry Controller Status