- 27 Nov, 2006 1 commit
-
-
wolfgang.thaller@gmx.net authored
Basic -fvia-C code generation is there, not much testing.
-
- 24 Nov, 2006 2 commits
-
-
wolfgang.thaller@gmx.net authored
We can avoid using any other long long operations in PrimOps.cmm. One more step towards compiling the RTS using the NCG.
-
wolfgang.thaller@gmx.net authored
This is a follow-up to "NCG: Handle loops in register allocator". The newly-introduced invariant that every virtual register is always assigned to the same spill slot wasn't kept under all circumstances. *Now* memory-to-memory moves should never be required when compiling hand-written cmm code.
-
- 20 Nov, 2006 1 commit
-
-
wolfgang.thaller@gmx.net authored
We can't use lazy binding for tail-calls accross shared libraries, because dyld will crash due to incorrect stack layout. We can't get the stack alignment right for both cross-library tailcalls and foreign calls, so we have to bypass the stub code altogether and load the address to branch to from the non-lazy pointer table.
-
- 22 Oct, 2006 2 commits
-
-
wolfgang.thaller@gmx.net authored
This is needed for position-independent code on Mac OS X (both i386 and powerpc), when compiling the RTS with -fasm.
-
wolfgang.thaller@gmx.net authored
... 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.
-
- 25 Nov, 2006 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 05 Nov, 2006 1 commit
-
-
kolmodin@dtek.chalmers.se authored
Command 'check': print a list of all packages that are broken and which dependencies they are missing. Command 'list': updated by making it put brackets around broken packages.
-
- 24 Nov, 2006 11 commits
-
-
simonpj@microsoft.com authored
Lazy patterns are quite tricky! Consider f ~(C x) = 3 Can the Num constraint from the 3 be discharged by a Num dictionary bound by the pattern? Definitely not! See Note [Hopping the LIE in lazy patterns] in TcPat The type checker wasn't ensuring this, and that was causing all manner of strange things to happen. It actually manifested as a strictness bug reported by Sven Panne. I've added his test case as tcrun040.
-
sven.panne@aedion.de authored
-
Simon Marlow authored
-
simonpj@microsoft.com authored
SpecConstr was conservative about avoiding reboxing (see Note [Reboxing]) but that meant it lost useful opportunities. This patch makes it much more aggressive, but at the risk of doing some reboxing. Actually, the strictness analyser has the same property (it's possible for it to generate reboxing code, and thus increase allocation), but we don't worry so much about that. Maybe we should. Ideally, one would do some more sophisticated analysis that spotted the reboxing cases without excluding the useful ones. But meanwhile, let's try this.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
A message to Haskell Cafe from Grzegorz Chrupala made me realise that GHC was not handling implicit parameters correctly, when it comes to choosing the variables to quantify, and ambiguity tests. Here's the note I added to TcSimplify: Note [Implicit parameters and ambiguity] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What type should we infer for this? f x = (show ?y, x::Int) Since we must quantify over the ?y, the most plausible type is f :: (Show a, ?y::a) => Int -> (String, Int) But notice that the type of the RHS is (String,Int), with no type varibables mentioned at all! The type of f looks ambiguous. But it isn't, because at a call site we might have let ?y = 5::Int in f 7 and all is well. In effect, implicit parameters are, well, parameters, so we can take their type variables into account as part of the "tau-tvs" stuff. This is done in the function 'FunDeps.grow'. The actual changes are in FunDeps.grow, and the tests are tc219, tc219
-
simonpj@microsoft.com authored
The matching algorithm for RULES should respect alpha-conversion, but it wasn't doing so. In particular, if the names of the template variables clashed with a variable in scope at the call site, bad things could happen (it showed up as a CoreLint failure when compiling nofib/real/parser) This patch fixes the problem; see Note [Template binders] Test is in simplCore/should_compile/spec002, but nofib -O2 in real/parser, real/fulsom
-
simonpj@microsoft.com authored
We were getting too many cases where different expressions map to the same hash code (which shows up in CSE). This patch tries to improve the hash algorithm a bit.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Provoked by a suggestion of Simon's, this patch makes a half-hearted attempt to gather constraints in program order, so that we tend to report an error at its first occurrence, rather than its last. Examples: mdofail001, tcfail015 It's "half-hearted" because generally-speaking the typechecker does not guaranteed to keep constraints in order; it treats them as a set. Nevertheless this very small change seems to improve matters, so it seems a good one.
-
- 23 Nov, 2006 2 commits
-
-
simonpj@microsoft.com authored
For a long time TcSimplify used a three-way classification of constraints, into Free Irred ReduceMe (see the data type WhatToDo). In the new world of implication constraints, the Free case does not make so much sense, and I managed to elminate it altogether, thus simplifying the story somewhat. Now WhatToDo has constructors Stop ReduceMe There should be no change in behaviour.
-
Simon Marlow authored
-
- 22 Nov, 2006 7 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
We want to do tcSimplifyTop after checkMain, because checkMain can add useful type information that eliminates ambiguity. E.g. main = return undefined This is the way it used to be in 6.6, and I think I mistakenly moved it when doing implication constraints. This patch effectively puts it back the way it was. Cures the cg053 failure.
-
simonpj@microsoft.com authored
When simplifying an implication constraint (reduceImplication), if we make progress, make a new implication constraint for the result. If we don't do this, we get a constraint that can be simplified in a unique way, and that in turn confuses reportNoInstance
-
simonpj@microsoft.com authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
fixes ffi009(threaded1)
-
- 21 Nov, 2006 6 commits
-
-
David Himmelstrup authored
StableRoots opened new possibilities in the world of plugins with their ability to link partially applied closures against object code. Exporting '(fn pluginwideState)' severely reduced the complexity of HIDE's plugin system. The previous system of global variables was both fragile and hard to scale. Good bye, StableRoots. We sure had some fun.
-
Simon Marlow authored
-
Simon Marlow authored
In the free list, we don't strictly speaking need to have every block in a coalesced group point to the head block, although this is an invariant for non-free blocks. Dropping this invariant for the free list means that coalesce() is O(1) rather than O(N), and freeGroup() is therefore O(N) not O(N^2). The bad case probably didn't happen most of the time, indeed it has never shown up in a profile that I've seen. I had a report from a while back that this was a problem with really large heaps, though. Fortunately the fix is easy.
-
Ian Lynagh authored
It looks like this was just commented out while FC was being developed.
-
Simon Marlow authored
-
wolfgang.thaller@gmx.net authored
Apparently, the original fix never really worked due to typos and oversights.
-
- 20 Nov, 2006 4 commits
-
-
wolfgang.thaller@gmx.net authored
-
Ian Lynagh authored
-
Ian Lynagh authored
This is overly conservative, but it works.
-
Simon Marlow authored
Add GhcRtsWithPapi=YES to mk/build.mk to turn it on
-
- 09 Nov, 2006 1 commit
-
-
mrchebas@gmail.com authored
-