summaryrefslogtreecommitdiff
path: root/compiler/ghci/ByteCodeGen.lhs
Commit message (Collapse)AuthorAgeFilesLines
* Support code generation for unboxed-tuple function argumentsunboxed-tuple-arguments2Max Bolingbroke2012-05-151-12/+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
* Handle cases with no alternatives in GHCiSimon Marlow2012-05-111-0/+3
| | | | Fixes cgrun045(ghci) amongst others
* Support large SLIDE instructions.Paolo Capriotti2012-04-161-44/+66
| | | | | | | | | | | | | The bytecode generator used to keep track of the stack depth with a 16-bit counter, which could overflow for very large BCOs, resulting in incorrect bytecode. This commit switches to a word-sized counter, and eagerly panics whenever an operand is too big, instead of truncating the result. This allows us to work around the 16-bit limitation in the case of SLIDE instructions, since we can simply factor it into multiple SLIDEs with smaller arguments.
* Implement "value" imports with the CAPIIan Lynagh2012-02-261-1/+3
| | | | | | This allows us to import values (i.e. non-functions) with the CAPI. This means we can access values even if (on some or all platforms) they are simple #defines.
* 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.
* Fix gratuitous code duplication in the byte code generatorSimon Marlow2011-11-021-16/+34
| | | | | | | | For a case expression with a default, we were re-emitting the code for the default branch each time it was referenced, which in a case with many branches could be many times, leading to an O(n^2) blowup. This shows up in ghcirun003, which now runs much faster than before.
* Overhaul of infrastructure for profiling, coverage (HPC) and breakpointsSimon Marlow2011-11-021-84/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | User visible changes ==================== Profilng -------- Flags renamed (the old ones are still accepted for now): OLD NEW --------- ------------ -auto-all -fprof-auto -auto -fprof-exported -caf-all -fprof-cafs New flags: -fprof-auto Annotates all bindings (not just top-level ones) with SCCs -fprof-top Annotates just top-level bindings with SCCs -fprof-exported Annotates just exported bindings with SCCs -fprof-no-count-entries Do not maintain entry counts when profiling (can make profiled code go faster; useful with heap profiling where entry counts are not used) Cost-centre stacks have a new semantics, which should in most cases result in more useful and intuitive profiles. If you find this not to be the case, please let me know. This is the area where I have been experimenting most, and the current solution is probably not the final version, however it does address all the outstanding bugs and seems to be better than GHC 7.2. Stack traces ------------ +RTS -xc now gives more information. If the exception originates from a CAF (as is common, because GHC tends to lift exceptions out to the top-level), then the RTS walks up the stack and reports the stack in the enclosing update frame(s). Result: +RTS -xc is much more useful now - but you still have to compile for profiling to get it. I've played around a little with adding 'head []' to GHC itself, and +RTS -xc does pinpoint the problem quite accurately. I plan to add more facilities for stack tracing (e.g. in GHCi) in the future. Coverage (HPC) -------------- * derived instances are now coloured yellow if they weren't used * likewise record field names * entry counts are more accurate (hpc --fun-entry-count) * tab width is now correct (markup was previously off in source with tabs) Internal changes ================ In Core, the Note constructor has been replaced by Tick (Tickish b) (Expr b) which is used to represent all the kinds of source annotation we support: profiling SCCs, HPC ticks, and GHCi breakpoints. Depending on the properties of the Tickish, different transformations apply to Tick. See CoreUtils.mkTick for details. Tickets ======= This commit closes the following tickets, test cases to follow: - Close #2552: not a bug, but the behaviour is now more intuitive (test is T2552) - Close #680 (test is T680) - Close #1531 (test is result001) - Close #949 (test is T949) - Close #2466: test case has bitrotted (doesn't compile against current version of vector-space package)
* Make a new type synonym CoreProgram = [CoreBind]Simon Peyton Jones2011-09-231-1/+1
| | | | | | | | | | | and comment its invariants in Note [CoreProgram] in CoreSyn I'm not totally convinced that CoreProgram is the right name (perhaps CoreTopBinds might better), but it is useful to have a clue that you are looking at the top-level bindings. This is only a matter of a type synonym change; no deep refactoring here.
* Improve the handling of Integer literalsIan Lynagh2011-09-171-1/+1
| | | | | | | | | LitInteger now carries around the id of mkInteger, which it uses to construct the core to build Integer literals. This way we don't have to build in info about lots of Ids. We also no longer have any special-casing for integer-simple, so there is less code involved.
* change how Integer's are handled in CoreIan Lynagh2011-09-131-0/+4
| | | | | | We now treat them as literals until CorePrep, when we finally convert them into the real Core representation. This makes it a lot simpler to implement built-in rules on them.
* refactoring and fixing the stage 2 compilationSimon Marlow2011-08-251-0/+1
|
* 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
* fix warningSimon Marlow2011-07-201-1/+0
|
* Support 64-bit literals in the byte code generator (fixes recent testSimon Marlow2011-07-201-1/+3
| | | | failures in print002 etc. on 32-bit platforms)
* Fix Trac #5268: missing case for bytecode generation involving coercionsSimon Peyton Jones2011-06-231-22/+18
|
* Merge ghc-new-co into master branchSimon Peyton Jones2011-05-091-15/+16
|\
| * Missing coercion case in byte code generationSimon Peyton Jones2011-05-061-3/+4
| |
| * A few more wibbles on ghc-new-coSimon Peyton Jones2011-05-021-0/+1
| |
| * This BIG PATCH contains most of the work for the New Coercion RepresentationSimon Peyton Jones2011-04-191-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | See the paper "Practical aspects of evidence based compilation in System FC" * Coercion becomes a data type, distinct from Type * Coercions become value-level things, rather than type-level things, (although the value is zero bits wide, like the State token) A consequence is that a coerion abstraction increases the arity by 1 (just like a dictionary abstraction) * There is a new constructor in CoreExpr, namely Coercion, to inject coercions into terms
* | Remove a use of cTargetOS, in favour of platformOSIan Lynagh2011-05-081-2/+2
| |
* | Whitespace only in ghci/ByteCodeGen.lhsIan Lynagh2011-05-081-363/+363
| |
* | Remove an explicit import listIan Lynagh2011-05-081-1/+1
| |
* | Remove commented out importsIan Lynagh2011-05-081-4/+0
|/
* Allow enumerations to have phantom arguments.simonpj@microsoft.com2010-12-151-2/+2
| | | | | The bytecode generator was being too eager. Fixes Trac #4528, or rather, a near variant.
* Remove unncessary fromIntegral callssimonpj@microsoft.com2010-11-161-1/+1
|
* Use takeUniqFromSupply in ByteCodeGenIan Lynagh2010-10-211-3/+3
|
* Interruptible FFI calls with pthread_kill and CancelSynchronousIO. v4Edward Z. Yang2010-09-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | This is patch that adds support for interruptible FFI calls in the form of a new foreign import keyword 'interruptible', which can be used instead of 'safe' or 'unsafe'. Interruptible FFI calls act like safe FFI calls, except that the worker thread they run on may be interrupted. Internally, it replaces BlockedOnCCall_NoUnblockEx with BlockedOnCCall_Interruptible, and changes the behavior of the RTS to not modify the TSO_ flags on the event of an FFI call from a thread that was interruptible. It also modifies the bytecode format for foreign call, adding an extra Word16 to indicate interruptibility. The semantics of interruption vary from platform to platform, but the intent is that any blocking system calls are aborted with an error code. This is most useful for making function calls to system library functions that support interrupting. There is no support for pre-Vista Windows. There is a partner testsuite patch which adds several tests for this functionality.
* Remove use of lambda with a refutable patternsimonpj@microsoft.com2010-09-231-26/+24
|
* Remove (most of) the FiniteMap wrapperIan Lynagh2010-09-141-14/+18
| | | | | | | | We still have insertList, insertListWith, deleteList which aren't in Data.Map, and foldRightWithKey which works around the fold(r)WithKey addition and deprecation.
* Super-monster patch implementing the new typechecker -- at lastsimonpj@microsoft.com2010-09-131-3/+5
| | | | | | | | | This major patch implements the new OutsideIn constraint solving algorithm in the typecheker, following our JFP paper "Modular type inference with local assumptions". Done with major help from Dimitrios Vytiniotis and Brent Yorgey.
* Refactor PackageTarget back into StaticTargetBen.Lippmeier@anu.edu.au2010-01-041-14/+1
|
* Follow PackageTarget change in byte code generatorBen.Lippmeier@anu.edu.au2010-01-021-0/+14
|
* implement case-on-Word in the byte code generator/interpreter (#2881)Simon Marlow2009-09-181-0/+10
|
* Windows build fixSimon Marlow2009-08-031-1/+1
|
* If ghci runs out of labels, panicIan Lynagh2009-08-011-1/+4
|
* Remove some redundant fromIntegral'sIan Lynagh2009-07-301-2/+2
|
* Make the types we use when creating GHCi bytecode better match realityIan Lynagh2009-07-291-51/+61
| | | | | We were keeping things as Int, and then converting them to Word16 at the last minute, when really they ought to have been Word16 all along.
* Trim unused imports detected by new unused-import codesimonpj@microsoft.com2009-07-061-3/+3
|
* FIX #2845: Allow breakpoints on expressions with unlifted typeSimon Marlow2009-04-201-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | It turns out we can easily support breakpoints on expressions with unlifted types, by translating case tick# of _ -> e into let f = \s . case tick# of _ -> e in f realWorld# instead of just a plain let-binding. This is the same trick that GHC uses for abstracting join points of unlifted type. In #2845, GHC has eta-expanded the tick expression, changing the result type from IO a to (# State#, a #), which was the reason the tick was suddenly being ignored. By supporting ticks on unlifted expressions we can make it work again, although some confusion might arise because _result will no longer be available (it now has unboxed-tuple type, so we can't bind it in the environment). The underlying problem here is that GHC does transformations like eta-expanding the tick expressions, and there's nothing we can do to prevent that.
* When generating C, don't pretend functions are dataIan Lynagh2009-02-061-1/+1
| | | | | | | | | | | | | | | We used to generated things like: extern StgWordArray (newCAF) __attribute__((aligned (8))); ((void (*)(void *))(W_)&newCAF)((void *)R1.w); (which is to say, pretend that newCAF is some data, then cast it to a function and call it). This goes wrong on at least IA64, where: A function pointer on the ia64 does not point to the first byte of code. Intsead, it points to a structure that describes the function. The first quadword in the structure is the address of the first byte of code so we end up dereferencing function pointers one time too many, and segfaulting.
* Tidy up treatment of big lambda (fixes Trac #2898)simonpj@microsoft.com2008-12-301-48/+43
| | | | | | | | | | There was a leftover big lambda in the CorePrep'd code, which confused the bytecode generator. Actually big lambdas are harmless. This patch refactors ByteCodeGen so that it systemantically used 'bcView' to eliminate junk. I did a little clean up in CorePrep too. See comments in Trac #2898.
* Comments only. Fix typo.Thomas Schilling2008-12-111-1/+1
|
* pushAtom: add missing case for MachNullAddr (#2589)Simon Marlow2008-10-091-0/+1
|
* Follow extensible exception changesIan Lynagh2008-07-301-2/+1
|
* validate fix: eliminate a warning on non-WindowsSimon Marlow2008-05-151-2/+2
|
* FIX #1288: GHCi wasn't adding the @n suffix to stdcalls on WindowsSimon Marlow2008-05-141-2/+13
|
* Make ByteCodeGen warning-freeIan Lynagh2008-05-041-67/+58
|
* (F)SLIT -> (f)sLit in ByteCodeGenIan Lynagh2008-04-121-2/+2
|
* Import libffi-3.0.4, and use it to provide FFI support in GHCiSimon Marlow2008-04-081-10/+0
| | | | | | | | | | | | | | | | | | | | This replaces the hand-rolled architecture-specific FFI support in GHCi with the standard libffi as used in GCJ, Python and other projects. I've bundled the complete libffi-3.0.4 tarball in the source tree in the same way as we do for GMP, the difference being that we always build and install our own libffi regardless of whether there's one on the system (it's small, and we don't want dependency/versioning headaches). In particular this means that unregisterised builds will now have a fully working GHCi including FFI out of the box, provided libffi supports the platform. There is also code in the RTS to use libffi in place of rts/Adjustor.c, but it is currently not enabled if we already have support in Adjustor.c for the current platform. We need to assess the performance impact before using libffi here too (in GHCi we don't care too much about performance).
* Support for using libffi to implement FFI calls in GHCi (#631)Simon Marlow2008-02-041-38/+57
| | | | | | | | | | | | This means that an unregisterised build on a platform not directly supported by GHC can now have full FFI support using libffi. Also in this commit: - use PrimRep rather than CgRep to describe FFI args in the byte code generator. No functional changes, but PrimRep is more correct. - change TyCon.sizeofPrimRep to primRepSizeW, which is more useful
View Lorry Controller Status