- 25 Aug, 2011 1 commit
-
-
Simon Marlow authored
-
- 29 Jul, 2011 3 commits
-
-
batterseapower authored
-
batterseapower authored
-
Simon Peyton Jones authored
-
- 28 Jul, 2011 3 commits
-
-
batterseapower authored
-
batterseapower authored
-
batterseapower authored
-
- 15 Jul, 2011 1 commit
-
-
Ian Lynagh authored
There's now a variant of the Outputable class that knows what platform we're targetting: class PlatformOutputable a where pprPlatform :: Platform -> a -> SDoc pprPlatformPrec :: Platform -> Rational -> a -> SDoc and various instances have had to be converted to use that class, and we pass Platform around accordingly.
-
- 07 Jul, 2011 1 commit
-
-
batterseapower authored
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.
-
- 05 Jul, 2011 1 commit
-
-
batterseapower authored
-
- 01 May, 2011 1 commit
-
-
Ian Lynagh authored
We now test cGhcWithNativeCodeGen == "YES" instead.
-
- 30 Apr, 2011 1 commit
-
-
Ian Lynagh authored
This is more pleasant than having the C generator check whether the function it's calling is cas, and not generate a prototype if so.
-
- 19 Apr, 2011 1 commit
-
-
Ian Lynagh authored
I'm not sure if this is the best way to fix this, but it fixes the unreg build.
-
- 12 Apr, 2011 1 commit
-
-
Simon Marlow authored
Previously the code generator generated small code fragments labelled with __stginit_M for each module M, and these performed whatever initialisation was necessary for that module and recursively invoked the initialisation functions for imported modules. This appraoch had drawbacks: - FFI users had to call hs_add_root() to ensure the correct initialisation routines were called. This is a non-standard, and ugly, API. - unless we were using -split-objs, the __stginit dependencies would entail linking the whole transitive closure of modules imported, whether they were actually used or not. In an extreme case (#4387, #4417), a module from GHC might be imported for use in Template Haskell or an annotation, and that would force the whole of GHC to be needlessly linked into the final executable. So now instead we do our initialisation with C functions marked with __attribute__((constructor)), which are automatically invoked at program startup time (or DSO load-time). The C initialisers are emitted into the stub.c file. This means that every time we compile with -prof or -hpc, we now get a stub file, but thanks to #3687 that is now invisible to the user. There are some refactorings in the RTS (particularly for HPC) to handle the fact that initialisers now get run earlier than they did before. The __stginit symbols are still generated, and the hs_add_root() function still exists (but does nothing), for backwards compatibility.
-
- 22 Mar, 2011 1 commit
-
-
Edward Z. Yang authored
-
- 29 Mar, 2010 1 commit
-
-
Simon Marlow authored
This replaces the global blackhole_queue with a clever scheme that enables us to queue up blocked threads on the closure that they are blocked on, while still avoiding atomic instructions in the common case. Advantages: - gets rid of a locked global data structure and some tricky GC code (replacing it with some per-thread data structures and different tricky GC code :) - wakeups are more prompt: parallel/concurrent performance should benefit. I haven't seen anything dramatic in the parallel benchmarks so far, but a couple of threading benchmarks do improve a bit. - waking up a thread blocked on a blackhole is now O(1) (e.g. if it is the target of throwTo). - less sharing and better separation of Capabilities: communication is done with messages, the data structures are strictly owned by a Capability and cannot be modified except by sending messages. - this change will utlimately enable us to do more intelligent scheduling when threads block on each other. This is what started off the whole thing, but it isn't done yet (#3838). I'll be documenting all this on the wiki in due course.
-
- 06 Jan, 2010 1 commit
-
-
Ian Lynagh authored
From Maxime Henrion <mhenrion@gmail.com>
-
- 02 Jan, 2010 3 commits
-
-
Ben.Lippmeier.anu.edu.au authored
-
Ben.Lippmeier@anu.edu.au authored
-
Ben.Lippmeier@anu.edu.au authored
-
- 29 Dec, 2009 1 commit
-
-
Ben.Lippmeier@anu.edu.au authored
-
- 06 Nov, 2009 2 commits
-
-
Ben.Lippmeier@anu.edu.au authored
-
Ben.Lippmeier@anu.edu.au authored
The type of the CmmLabel ctor is now CmmLabel :: PackageId -> FastString -> CmmLabelInfo -> CLabel - When you construct a CmmLabel you have to explicitly say what package it is in. Many of these will just use rtsPackageId, but I've left it this way to remind people not to pretend labels are in the RTS package when they're not. - When parsing a Cmm file, labels that are not defined in the current file are assumed to be in the RTS package. Labels imported like import label are assumed to be in a generic "foreign" package, which is different from the current one. Labels imported like import "package-name" label are marked as coming from the named package. This last one is needed for the integer-gmp library as we want to refer to labels that are not in the same compilation unit, but are in the same non-rts package. This should help remove the nasty #ifdef __PIC__ stuff from integer-gmp/cbits/gmp-wrappers.cmm
-
- 22 Oct, 2009 1 commit
-
-
Ben.Lippmeier@anu.edu.au authored
-
- 18 Oct, 2009 3 commits
-
-
Ben.Lippmeier@anu.edu.au authored
-
Ben.Lippmeier@anu.edu.au authored
-
Ben.Lippmeier@anu.edu.au authored
-
- 03 Aug, 2009 1 commit
-
-
Simon Marlow authored
For consistency with other RTS exported symbols
-
- 09 Jun, 2009 1 commit
-
-
Duncan Coutts authored
It adds a third case to StgOp which already hold StgPrimOp and StgFCallOp. The code generation for the new StgPrimCallOp case is almost exactly the same as for out-of-line primops. They now share the tailCallPrim function. In the Core -> STG translation we map foreign calls using the "prim" calling convention to the StgPrimCallOp case. This is because in Core we represent prim calls using the ForeignCall stuff. At the STG level however the prim calls are really much more like primops than foreign calls.
-
- 23 May, 2009 1 commit
-
-
Austin Seipp authored
-
- 30 Mar, 2009 1 commit
-
-
Simon Marlow authored
-
- 23 Mar, 2009 1 commit
-
-
Bertram Felgenhauer authored
Fix via C compilation of modules that import, say, log1p from math.h (#3117) The list is based on preprocessing Stg.h with glibc 2.6.1 headers, and cross-checked with the ISO C 99 standard (draft).
-
- 06 Feb, 2009 1 commit
-
-
Ian Lynagh authored
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.
-
- 13 Oct, 2008 1 commit
-
-
dias@eecs.harvard.edu authored
o Fixed bug that emitted the copy-in code for closure entry in the wrong place -- at the initialization of the closure. o Refactored some of the closure entry code. o Added code to check that no LocalRegs are live-in to a procedure -- trip up some buggy programs earlier o Fixed environment bindings for thunks -- we weren't (re)binding the free variables in a thunk o Fixed a bug in proc-point splitting that dropped some updates to the entry block in a procedure. o Fixed improper calls to code that generates CmmLit's for strings o New invariant on cg_loc in CgIdInfo: the expression is always tagged o Code to load free vars on entry to a thunk was (wrongly) placed before the heap check. o Some of the StgCmm code was redundantly passing around Id's along with CgIdInfo's; no more. o Initialize the LocalReg's that point to a closure before allocating and initializing the closure itself -- otherwise, we have problems with recursive closure bindings o BlockEnv and BlockSet types are now abstract. o Update frames: - push arguments in Old call area - keep track of the return sp in the FCode monad - keep the return sp in every call, tail call, and return (because it might be different at different call sites, e.g. tail calls to the gc after a heap check are performed before pushing the update frame) - set the sp appropriately on returns and tail calls o Reduce call, tail call, and return to a single LastCall node o Added slow entry code, using different calling conventions on entry and tail call o More fixes to the calling convention code. The tricky stuff is all about the closure environment: it must be passed in R1, but in non-closures, there is no such argument, so we can't treat all arguments the same way: the closure environment is special. Maybe the right step forward would be to define a different calling convention for closure arguments. o Let-no-escapes need to be emitted out-of-line -- otherwise, we drop code. o Respect RTS requirement of word alignment for pointers My stack allocation can pack sub-word values into a single word on the stack, but it wasn't requiring word-alignment for pointers. It does now, by word-aligning both pointer registers and call areas. o CmmLint was over-aggresively ruling out non-word-aligned memory references, which may be kosher now that we can spill small values into a single word. o Wrong label order on a conditional branch when compiling switches. o void args weren't dropped in many cases. To help prevent this kind of mistake, I defined a NonVoid wrapper, which I'm applying only to Id's for now, although there are probably other good candidates. o A little code refactoring: separate modules for procpoint analysis splitting, stack layout, and building infotables. o Stack limit check: insert along with the heap limit check, using a symbolic constant (a special CmmLit), then replace it when the stack layout is known. o Removed last node: MidAddToContext o Adding block id as a literal: means that the lowering of the calling conventions no longer has to produce labels early, which was inhibiting common-block elimination. Will also make it easier for the non-procpoint-splitting path. o Info tables: don't try to describe the update frame! o Over aggressive use of NonVoid!!!! Don't drop the non-void args before setting the type of the closure!!! o Sanity checking: Added a pass to stub dead dead slots on the stack (only ~10 lines with the dataflow framework) o More sanity checking: Check that incoming pointer arguments are non-stubbed. Note: these checks are still subject to dead-code removal, but they should still be quite helpful. o Better sanity checking: why stop at function arguments? Instead, in mkAssign, check that _any_ assignment to a pointer type is non-null -- the sooner the crash, the easier it is to debug. Still need to add the debugging flag to turn these checks on explicitly. o Fixed yet another calling convention bug. This time, the calls to the GC were wrong. I've added a new convention for GC calls and invoked it where appropriate. We should really straighten out the calling convention stuff: some of the code (and documentation) is spread across the compiler, and there's some magical use of the node register that should really be handled (not avoided) by calling conventions. o Switch bug: the arms in mkCmmLitSwitch weren't returning to a single join point. o Environment shadowing problem in Stg->Cmm: When a closure f is bound at the top-level, we should not bind f to the node register on entry to the closure. Why? Because if the body of f contains a let-bound closure g that refers to f, we want to make sure that it refers to the static closure for f. Normally, this would all be fine, because when we compile a closure, we rebind free variables in the environment. But f doesn't look like a free variable because it's a static value. So, the binding for f remains in the environment when we compile g, inconveniently referring to the wrong thing. Now, I bind the variable in the local environment only if the closure is not bound at the top level. It's still okay to make assumptions about the node holding the closure environment; we just won't find the binding in the environment, so code that names the closure will now directly get the label of the static closure, not the node register holding a pointer to the static closure. o Don't generate bogus Cmm code containing SRTs during the STG -> Cmm pass! The tables made reference to some labels that don't exist when we compute and generate the tables in the back end. o Safe foreign calls need some special treatment (at least until we have the integrated codegen). In particular: o they need info tables o they are not procpoints -- the successor had better be in the same procedure o we cannot (yet) implement the calling conventions early, which means we have to carry the calling-conv info all the way to the end o We weren't following the old convention when registering a module. Now, we use update frames to push any new modules that have to be registered and enter the youngest one on the stack. We also use the update frame machinery to specify that the return should pop the return address off the stack. o At each safe foreign call, an infotable must be at the bottom of the stack, and the TSO->sp must point to it. o More problems with void args in a direct call to a function: We were checking the args (minus voids) to check whether the call was saturated, which caused problems when the function really wasn't saturated because it took an extra void argument. o Forgot to distinguish integer != from floating != during Stg->Cmm o Updating slotEnv and areaMap to include safe foreign calls The dataflow analyses that produce the slotEnv and areaMap give results for each basic block, but we also need the results for a safe foreign call, which is a middle node. After running the dataflow analysis, we have another pass that updates the results to includ any safe foreign calls. o Added a static flag for the debugging technique that inserts instructions to stub dead slots on the stack and crashes when a stubbed value is loaded into a pointer-typed LocalReg. o C back end expects to see return continuations before their call sites. Sorted the flowgraphs appropriately after splitting. o PrimOp calling conventions are special -- unlimited registers, no stack Yet another calling convention... o More void value problems: if the RHS of a case arm is a void-typed variable, don't try to return it. o When calling some primOp, they may allocate memory; if so, we need to do a heap check when we return from the call.
-
- 14 Aug, 2008 1 commit
-
-
dias@eecs.harvard.edu authored
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
-
- 18 Nov, 2008 1 commit
-
-
Simon Marlow authored
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.
-
- 25 Jul, 2008 1 commit
-
-
Simon Marlow authored
Saves space in the symbol table and speeds up linking
-
- 11 Jul, 2008 1 commit
-
-
Simon Marlow authored
-
- 14 May, 2008 1 commit
-
-
Simon Marlow authored
This turned out not to be too hard, just a matter of figuring out the correct argument list size by peeking inside FunPtr's type argument, and in the C backend we have to emit an appropriate prototype for the label.
-
- 23 Apr, 2008 1 commit
-
-
rl@cse.unsw.edu.au authored
-