[GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples

[GHC]

#9390: Inlining prevents evaluation of ignored parts of unboxed tuples
-------------------------------------+-------------------------------------
              Reporter:  snoyberg    |            Owner:
                  Type:  bug         |           Status:  new
              Priority:  normal      |        Milestone:  7.8.4
             Component:  Compiler    |          Version:  7.8.3
            Resolution:              |         Keywords:
      Operating System:  Linux       |     Architecture:  x86_64 (amd64)
       Type of failure:  Incorrect   |       Difficulty:  Unknown
  result at runtime                  |       Blocked By:
             Test Case:              |  Related Tickets:
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by snoyberg):

 I think so, let me see if I've got a grasp of this. In Carter's example
 above, there are essentially the following steps:

 1. Create a new vector.
 2. Write 'A' into the vector.
 3. Write 'B' into the vector.
 4. Freeze and print the vector.

 The ordering dependencies in the code are as follows:

 * Steps 2, 3, and 4 all depend on step 1 occurring.
 * Step 4 depends on step 2 (due to ordering in the IO monad) and step 3
 (due to the usage of seq).

 However, there is no clearly expressed ordering between 2 and 3. Even
 those we only force evaluation of step 3's thunk "after" step 2 is
 performed, there is nothing in the code to express this as a strict
 ordering requirement, and therefore GHC is at full liberty to perform step
 3 before step 2.

 In your code, however, by using `unsafeInterleaveIO`, we have in fact
 stated a strict ordering requirement that step 3 occur after step 2, which
 solves the problem.

 And none of this has anything to do with my original example, which has to
 do with some primops being optimized away depending on how their resulting
 `State#` is handled (whether inside a `case` or not).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9390#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler