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