| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
I guess we have a missing test... I'll add one
|
|
|
|
| |
See comments with shift_code
|
|
|
|
|
| |
cvts[sd]2siq? ->
cvtts[sd]2siq?
|
| |
|
|
|
|
|
| |
We had a pattern that matched (base+(index<<N)), but not
(base+(index<<N)+M).
|
|
|
|
|
|
| |
We weren't catching some literals that actually fit in 32 bits before,
because e.g. -1 was sometimes represented as 0xffffffffffffffff in CmmInt.
|
| |
|
|
|
|
|
|
|
|
| |
This time, the PowerPC NCG suffered from a typo.
(I've really grown to hate all those #if foo_TARGET_ARCH
lines. I need to build GHC for at least four different
platforms just to make sure that there are no typos...)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Supporting x86_64-apple-darwin in the NCG basically boils down to supporting
position-independent code in the NCG.
PIC code works almost exactly the same as on x86_64-linux, while position-dependent
code is not supported at all.
This patch implements -fPIC for x86_64-linux, too, but that is untested.
|
|
|
|
|
|
|
| |
For varargs calls, CALL reads the %al register; record that fact for the benefit of the
register allocator.
(There was a previous attempt to do this, but it was broken.)
|
|
|
|
|
| |
We can avoid using any other long long operations in PrimOps.cmm.
One more step towards compiling the RTS using the NCG.
|
|
|
|
| |
Push this further along, and fix build problems in the first patch.
|
| |
|
|
|
|
| |
This will let us express write barriers in C--
|
| |
|
|
|
|
|
| |
The fix is a little hacky, because we don't have support for register
classes in general, but it's an improvement.
|
|
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.
|