ghc floats out constant despite -fno-cse

Consider this program using Data.Vector.unsafeThaw and -fno-cse:

{-# OPTIONS_GHC -fno-cse #-}

import qualified Data.Vector as V
import qualified Data.Vector.Mutable as VM

main :: IO ()
main = do
  foo 100000
  foo 100000

  let f = foo 100000 in f >> f

foo :: Int -> IO ()
foo n = do
  indexVector <- V.unsafeThaw $ V.generate n id

  x <- VM.read indexVector 5
  VM.write indexVector 5 (x * x)

  print x

-- In GHCI, we get:
--
-- > :set -fno-cse
--
-- > foo 100000
-- 5
-- > foo 100000
-- 5
--
-- > let f = foo 100000 in f >> f
-- 5
-- 25

I would expect that

> let f = foo 100000 in f >> f
5
5

Shouldn't -fno-cse fix this?

(Note: This also happens with ghc instead of ghci.)

changed weight to 5

added Tbug Trac import labels

changed title from ghci floats out constant despite -fno-cse, resulting in very unintuitive behaviour to ghci floats out constant despite -fno-cse

changed title from ghci floats out constant despite -fno-cse to ghc floats out constant despite -fno-cse

changed the description

Note that {-# OPTIONS_GHC -fno-full-laziness #-} also doesn't help here; how could I prevent the floating-out so that the use of unsafeThaw is safe?

Another note, using -O fixes the problem with -O, main prints:

5
5
5
5

This is using ghc 8.0.1 with vector from stackage lts-7.1.

Have you tried {-# NOINLINE foo #-}? With unsafe stuff, it is often important to keep this local.

I've verified that this happens with GHC 7.8 (lts-3) too.

nomeata: NOINLINE will prevent this behavior because there will be no opportunity for floating out the expression and eliminating it.

However, we're trying to understand why -fno-full-laziness -fno-cse does not prevent this, since it seems like it should.

Actually I spoke too soon: this doesn't work even with NOINLINE!

$ cat weird-float.hs 
import qualified Data.Vector as V
import qualified Data.Vector.Mutable as VM

main :: IO ()
main = do
  foo 100000
  foo 100000

  let f = foo 100000 in f >> f

{-# NOINLINE foo #-}
foo :: Int -> IO ()
foo n = do
  indexVector <- V.unsafeThaw $ V.generate n id
  x <- VM.read indexVector 5
  VM.write indexVector 5 (x * x)
  print x
$ stack exec --resolver lts-7 --package vector -- ghc -fforce-recomp -package vector -O0 -fno-full-laziness -fno-cse weird-float.hs -o weird-float-lts-7
Run from outside a project, using implicit global project config
Using resolver: lts-7 specified on command line
Selected resolver: lts-7.2
[1 of 1] Compiling Main             ( weird-float.hs, weird-float.o )
Linking weird-float-lts-7 ...
$ ./weird-float-lts-7 
5
5
5
25
$ stack exec --resolver lts-7 --package vector -- ghc --version                                                      
Run from outside a project, using implicit global project config
Using resolver: lts-7 specified on command line
Selected resolver: lts-7.2
The Glorious Glasgow Haskell Compilation System, version 8.0.1

First note that main (and thus -fno-cse) is a red herring, since the behavior under consideration is that of let f = foo 100000 in f >> f which does not mention main.

But this is just normal Haskell laziness in action, which becomes clear if you desugar foo.

foo :: Int -> IO ()
foo n = (>>=) (V.unsafeThaw $ V.generate n id) (...)

If you bind foo 100000 to a name f, then f's subexpression V.generate 100000 id will only ever be evaluated once during the lifetime of f. Moral: unsafeThaw is unsafe.

What's more mysterious is why you get the "expected" behavior from compiled code.

What's more mysterious is why you get the "expected" behavior from compiled code.

That could be the effect of the state hack, turning

    foo n = (>>=) (V.unsafeThaw $ V.generate n id) (...)

into

    foo n rw# = (>>=) (V.unsafeThaw $ V.generate n id) (...) rw#

and hence making foo 1000 a PAP where nothing is shared yet. (Did not look at the Core, though.)

rwbarton: You're very right -- the fact that it "worked" compiling normally threw us in a loop. Thanks for clarifying!

In light of this, I think we should warn people that unsafeThaw is way unsafer than the docs imply...

Oh I misread some of the earlier comments; it's only with -O that you get the "expected" behavior, while ghc without optimization behaves the same as ghci. Then there is no mystery (and indeed -fno-state-hack restores the non-optimized behavior as nomeata guessed).

In light of this, I think we should warn people that unsafeThaw is way unsafer than the docs imply...

Or at least that if you are going to use unsafeThaw then -fno-state-hack would be a good companion.

Simon

mentioned in issue #13080

added incorrect runtime result label

added Pnormal label

Here is another interesting aspect of this problem. When we add noinline on unsafeThaw to the mix we get some more inconsistent behavior:

foo :: Int -> IO ()
foo n = do
  indexVector <- noinline V.unsafeThaw $ V.generate n id

  x <- VM.read indexVector 5
  VM.write indexVector 5 (x * x)

  print x

Compiling with:

• ghc -O0 we get:

5
5
5
25

• ghc -O1:

5
5
5
5

• But when compiled with ghc -O1 -fno-state-hack:

5
25
625
390625

Further experimentation with -fno-cse and -fno-full-laziness revealed no difference in output.

So I am not quite sure what to make of it and what sort of guidelines we should document on the unsafeThaw functions in vector and in primitive.

To make matters even worse here is an example that doesn't depend on -fno-state-hack or any other flags that I tried for that matter:

  replicateM_ 5 $ do
    vm <- noinline V.unsafeThaw (V.generate 1 id)
    x <- VM.read vm 0
    print x
    VM.write vm 0 (100 + x)

This will print:

0
100
200
300
400

Naturally noinline doesn't have to be used, it would be enough that unsafeThaw was used in some function that is too big or recursive causing for it to not be inlined. This loop, for example, will do the trick:

loop n v = go 0
  where
    go i
      | i < n = putStrLn ("iter: " ++ show i) >> go (i + 1)
      | otherwise = V.unsafeThaw v

Maybe nofloat proposed in #12620 could be a solution here.