[project @ 2005-03-02 11:06:58 by simonmar]

[ghc-hetmet.git] / ghc / compiler / nativeGen / NOTES

diff --git a/ghc/compiler/nativeGen/NOTES b/ghc/compiler/nativeGen/NOTES
index f19375b..9068a7f 100644 (file)
--- a/ghc/compiler/nativeGen/NOTES
+++ b/ghc/compiler/nativeGen/NOTES
@@ -1,22 +1,41 @@
+TODO in new NCG
+~~~~~~~~~~~~~~~
 
-Known bugs in nativeGen, 000124 (JRS)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+- Are we being careful enough about narrowing those out-of-range CmmInts?
 
-All these bugs are for x86; I don't know about sparc/alpha.
+- Register allocator:
+    - fixup code
+    - keep track of free stack slots
 
--- argument marshalling for ccall is fundamentally flawed, since
-   it moves the C stack pointer %esp as it pushes each argument.
-   Alas, the register allocator spills relative to %esp and 
-   assumes that it doesn't move.  Result: if the marshalling code
-   for a ccall involves any spills, the resulting code will 
-   probably be wrong.
+    Optimisations:
 
-   The Right Way to fix this is to copy stuff onto the stack
-   without moving %esp, then adjust it immediately prior to the
-   call insn and un-adjust it immediately following it.
+    - picking the assignment on entry to a block: better to defer this
+      until we know all the assignments.  In a loop, we should pick
+      the assignment from the looping jump (fixpointing?), so that any
+      fixup code ends up *outside* the loop.  Otherwise, we should
+      pick the assignment that results in the least fixup code.
 
--- nofib/spectral/cvh_unboxing exposes some kind of spilling bug
-   (I think), since there are many references to registers %M229
-   etc, which I believe are dynamic registers which didn't get assigned
-   to real ones.
+- splitting?
+
+-- -----------------------------------------------------------------------------
+-- x86 ToDos
+
+- x86 genCCall needs to tack on the @size for stdcalls (might not be in the
+  foreignlabel).
+
+- x86: should really clean up that IMUL64 stuff, and tell the code gen about
+  Intel imul instructions.
+
+- x86: we're not careful enough about making sure that we only use
+  byte-addressable registers in byte instructions.  Should we do it this
+  way, or stick to using 32-bit registers everywhere?
+
+- Use SSE for floating point, optionally.
+
+------------------------------------------------------------------------------
+-- Further optimisations:
+
+- We might be able to extend the scope of the inlining phase so it can
+  skip over more statements that don't affect the value of the inlined
+  expr.