I think you'll find it useful to be explicit about what you are relying on. For example I think that if your program contains two calls unsafePerformIO e1 unsafePerformIO e2 then * You don't care about the *order* in which these are performed * You do care that they are both performed separately, even if e1=e2. That is, you do not want CSE (common sub-expression) * I'm not sure whether you care if they are not performed at all. E.g. if you have let x = unsafePerformIO e in True then GHC will discard the binding for x. You can control this by adding data dependencies, so that the body of the 'let' depends on 'x'. * I'm not sure if you care whether they are performed once or many times. E.g. f = \x. x + unsafePerformIO (h z) If the (h z) doesn't mention 'x', GHC will transform this to v = unsafePerformIO (h z) f = \x. x+v So now the effect happens once only, rather than once per call of f. Again you can control this by adding an articifical dependency on x. Adding these artificial dependencies may amount to exactly the kind of effect analysis that Joesef suggests. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Bernd Brassel | Sent: 17 October 2007 09:02 | To: glasgow-haskell-users@haskell.org | Subject: Prevent optimization from tempering with unsafePerformIO | | Hi David, | | thank you! This is really useful information! | | > I think it's the let floating (out) together with common subexpression | > elimination: | > | > > ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs | > [1 of 1] Compiling Main ( curry.hs, curry.o ) | > Linking curry-no-cse ... | > > ghc --make -O2 -no-recomp -fno-full-laziness -o curry-no-fll curry.hs | > [1 of 1] Compiling Main ( curry.hs, curry.o ) | > Linking curry-no-fll ... | > > ghc --make -O2 -no-recomp -fno-full-laziness -fno-cse -o | > curry-no-cse-no-fll curry.hs | > [1 of 1] Compiling Main ( curry.hs, curry.o ) | > Linking curry-no-cse-no-fll ... | > > ./curry-no-cse | > 3 possibilities: [True,False] | > 2 possibilities: [True,False] | > > ./curry-no-fll | > 3 possibilities: [True,False] | > 2 possibilities: [True,False] | > > ./curry-no-cse-no-fll | > 3 possibilities: [True,True,False] | > 2 possibilities: [True,False] | | I will try this on large scale Curry programs. I hope the remaining | optimizations will still do some good. Do you think that there is a way | to be more selective? I mean to select those parts of the program which | can and which cannot be optimized? | | > ps.: Maybe it is interesting to look at HasFuse [1] (somewhat outdated), | > but it exactly forbids both transformations | > | > [1] http://www.ki.informatik.uni-frankfurt.de/research/diamond/hasfuse/ | | Yes, that looks interesting, too. Are there plans to update it with the | ghc? | | Thanks for your hints! | Bernd | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users