Repository : ssh://darcs.haskell.org//srv/darcs/ghc

On branch  : master

http://hackage.haskell.org/trac/ghc/changeset/aed37acd4d157791381800d5de960a2461bcbef3

>---------------------------------------------------------------

commit aed37acd4d157791381800d5de960a2461bcbef3
Author: Simon Marlow <marlo...@gmail.com>
Date:   Thu Aug 9 16:55:15 2012 +0100

    Add a ToDo comment

>---------------------------------------------------------------

 compiler/cmm/CmmSink.hs |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/compiler/cmm/CmmSink.hs b/compiler/cmm/CmmSink.hs
index 7acc4dd..2ff9b98 100644
--- a/compiler/cmm/CmmSink.hs
+++ b/compiler/cmm/CmmSink.hs
@@ -465,6 +465,27 @@ data AbsMem
 -- Note that SpMem is invalidated if Sp is changed, but the definition
 -- of 'conflicts' above handles that.
 
+-- ToDo: this won't currently fix the following commonly occurring code:
+--    x1 = [R1 + 8]
+--    x2 = [R1 + 16]
+--    ..
+--    [Hp - 8] = x1
+--    [Hp - 16] = x2
+--    ..
+
+-- because [R1 + 8] and [Hp - 8] are both HeapMem.  We know that
+-- assignments to [Hp + n] do not conflict with any other heap memory,
+-- but this is tricky to nail down.  What if we had
+--
+--   x = Hp + n
+--   [x] = ...
+--
+--  the store to [x] should be "new heap", not "old heap".
+--  Furthermore, you could imagine that if we started inlining
+--  functions in Cmm then there might well be reads of heap memory
+--  that was written in the same basic block.  To take advantage of
+--  non-aliasing of heap memory we will have to be more clever.
+
 bothMems :: AbsMem -> AbsMem -> AbsMem
 bothMems NoMem    x         = x
 bothMems x        NoMem     = x



_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to