Re: [GHC] #9291: Don't reconstruct sum types if the type subtly changes

5 Dec 2016

      ...
I wonder if a better approach would be a STG-level CSE pass? (No types
#9291: Don't reconstruct sum types if the type subtly changes
-------------------------------------+-------------------------------------
        Reporter:  schyler           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.8.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 there!)

 Is general CSE on the STG level safe? We would have to pay attention not
 to CSE two invocations of `newSTRef`, for example! Consider

 {{{#!hs
 foo :: Integer -> Integer
 foo n = runST (newSTRef 1 >>= \r -> modifySTRef r (+n)   >> readSTRef r)
       + runST (newSTRef 1 >>= \r -> modifySTRef r (+2*n) >> readSTRef r)
 }}}
 which generated this STG
 {{{
 STGCSE.foo :: GHC.Integer.Type.Integer -> GHC.Integer.Type.Integer
 [GblId, Arity=1, Str=, Unf=OtherCon []] =
     \r [n_sQX]
         case
             case newMutVar# [STGCSE.foo2 GHC.Prim.realWorld#] of {
               Unit# ipv1_sR0 ->
 …
             }
         of
         { Unit# ipv1_sR8 [Occ=Once] ->
               case
                   case newMutVar# [STGCSE.foo2 GHC.Prim.realWorld#] of {
                     Unit# ipv3_sRb ->
 …
 }}}

 The two calls to `newMutVar#` look identical! But if we CSE them up, we
 change the semantics of the program.

 So it would require some form of „sideeffect-freeness“ analysis on STG.

 A simple form might be to CSE only constructor applications, and it would
 be sufficient for this issue. I guess it is good that `newMutVar#` does
 not get “inlined” to be just a constructor application at the STG stage. I
 wonder if there are constructor applications that we nevertheless do not
 want to CSE.

 The problem does not exist in Core, where `GHC.Magic.runRW#` is not
 inlined, and the types of `newMutVar#` do not match up.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9291#comment:32
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler